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READ IMAGE 
FLAGS 



A method of installing a software application image, for a 
software upgrade, within a remote and embedded target 
device includes the step of storing both a current and an 
upgraded software application image within an EEPROM 
within the target device. The set of instructions embodied 
within the current application image is maintained within the 
target device, while a validation operation is performed with 
respect to a set of instructions embodied within the upgraded 
software application image. Only once complete installation 
and successful execution of the upgraded application image 
have been validated is the upgraded application image 
designated as a current application image, and the previ- 
ously installed application image discarded. Accordingly, 
the risk of the target device being a rendered unbootable as 
a result of the installation of a software upgrade is reduced. 

32 Claims, 9 Drawing Sheets v & 
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METHOD AND APPARATUS FOR FIGS. 4 and 5 are block diagrams providing further details 

INSTALLING A SOFTWARE UPGRADE regarding a memory layout for an exemplary embodiment of 

WITHIN A MEMORY RESOURCE the present invention. 

ASSOCIATED WITH A COMPUTER SYSTEM FIGS. 6A and 6B are flowcharts illustrating a method, 

5 according to one exemplary embodiment of the present 

FIELD OF THE INVENTION invention, of installing a set of instructions, in the form of an 

The present invention relates generally to the field of application image, within a machine, 

software installation and, more specifically, to the field of FIG. 7 is a diagrammatic representation of an exemplary 

replacing a first set of instructions stored within a memory application image, illustrating a flag set associated with the 

resource associated with a machine, with a second set of 30 application image. 

instructions for execution by the machine. FIG. 8 is a flow chart illustrating a method, according to 

one exemplary embodiment of the present invention, of 

BACKGROUND OF THE INVENTION determining whether an object code image stored within a 

Microprocessors and microcontrollers are being used 15 memory resource is valid, 

increasingly in embedded applications to provide opera- DETAILED DESCRIPTION 
tional and functional intelligence within a wide variety of 

devices. It will be appreciated that the software stored within A method and apparatus for installing a software upgrade 

memories associated with such microprocessors and micro- within a memory resource associated with a computer 

controllers may require upgrading from time to time to 2 o system are described. In the following description, for the 

provide increased or modified Junctionality to a device in purposes of explanation, numerous specific details are set 
(whic tiltie rrucroproc essofor 'm jcroconjtr^er' is embedded^ forth in order to provide a thorough understanding of the 

With the proliferation of nelworks in a wide^variety ~of present invention. It will be evident, however, to one skilled 

applications, such as the home environment, software in the art that the present invention may be practiced without 

installed on a networked device may often conveniently be 2 s tnese specific details. 

upgraded from a remote location via the network. However, FIG. 1 is a diagrammatic representation of an exemplary 

it may occur that a networked device is positioned in a network environment 10 within which the present invention 

location which is difficult to access, or even inaccessible. may be employed. Specifically, a remote structure 12, for 

The remote upgrading of software stored within a memory example a small office or home, is shown to accommodate 

associated with the networked device may be problematic in 30 a local area network (LAN) 14 that networks a modem 16, 

that, should the upgrade installation fail for some reason, the a personal computer 18, a Macintosh 20, and a printer 22. 

networked device may be rendered totally inoperative. The The LAN 14 may be implemented utilizing Unshielded 

restoration of functionality to the network device may in Twisted Pair (U TP) wiring, power supply wiring, dedicated 

such cases be expensive and inconvenient. This is especially network wiring, or infrared connections, within the remote 

true when the networked device is being upgraded from a 35 structure 12. In one embodiment, the LAN 14 is imple- 

remote location, and service personnel are required to be mentedover UTP wiring within the remote location 12 using 

dispatched to the site of the networked device to address and the HomeRun™ networking technology developed by Tut 

correct the failed software upgrade operation. Systems, Inc. of Pleasant Hill, Calif. The modem 16 is 

shown to establish a communication link 24 to an Internet 

SUMMARY OF THE INVENTION 4Q Service Provider (ISP) 26 and, more specifically, to a hub 28 

According to the invention, there is provided a method of operated by the ISP 26. The communications link 24 may be 

installing a second set of instructions within a machine, the implemented over conventional plain old telephone service 

machine including a memory resource storing a first and the (POTS) wiring, and may comprise a Digital Subscriber Line 

second set of instructions. The machine executes the first set (DSL) link. Alternatively, the communications link may be 

of instructions, and validates the second set of instructions. 45 established via radio frequency communications, or satellite. 

If the second set of instructions is validated, the second set The hub 28 may include a number of cards (not shown) such 

of instructions is then indicated as being executable in place as, for example,_a management card, a line card, and a 

of the first set of instructions. switch card. Each of these cards may carry a processor, such- 

c ^ c . • *■ -ii u r~as the 68360 microprocessor manufactured, by Motorola 

Other features of the present invention will be apparent V_ _ ~.„ n ^ £ . *\ , r7 XT ™ • u- u .u 

r tL j j c . < j * * l j 50 ^Inc-The ISP 26 also implements a LAN 30, via which the 

from the accompanying drawings and from the detailed 3U " , ^ ""f 1 ^"" ° ' 

j • , f ,, hub 28 is networked or coupled to the public data network 

description that follows. .^ vrv . r r 

(PDN) via a router 34. 

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 2 is a block diagram illustrating an exemplary 

„ , , „ , embodiment of the composition of the modem 16. 

The present invention is illustrated by way of example, 55 s mcaJ1 the modem 16 is shown t0 include a bus 38 via 

and not limitation ; in the figures of the accompanying wfaich me various mmpoxn1s of lhe modem i6 CO mmuni- 

drawings m which like references indicate similar elements. ca(e and ^ imerfaced ^ modem 16 als0 indudes an 

FIG. 1 is a diagrammatic representation of a networked Ethernet interface 40 via which the modem 16 communi- 

environment within which the present invention may be cates over tne 14 In one embodiment, the Ethernet 

employed. 60 interface 40 facilitates lObaseT communications over the 

FIG. 2 is a block diagram illustrating an exemplary LAN 14. A processor 42, for example a 68302 processor 

machine in the form of a modem within which the present manufactured by Motorola Inc., an electrically erasable 

invention may be employed. programmable read-only memory (EEPRf^)JoM|ash„ 

FIG. 3 is a block diagram illustrating an exemplary memory ) 44, a UTP interface 46,[a7andom access memory- 
system memory layout, according to one embodiment of the 65 (RAM)^8_andjPnon-yo^ _memory> 
present invention, that may be implemented within the (NVRAM) 50 are a lsoa 11 shown to be coupled to the bus 38. 
memory of the machine illustrated in FIG. 2. The EEPROM 44 and the RAM 48 store sequences of 
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instructions that are executed by the processor 42 and that 
control operation of the modem 16. 

It will be appreciated that, from time to time, the manu- 
facturer of the modem 16 may wish to release upgraded 
software for installation and execution within the modem 
16. Typically, such an upgrade operation requires that the 
upgraded software be loaded into and stored within at least 
the EEPROM 44. One option would be to distribute the 
software to the user of the modem 16 (e.g., on a diskette or 
CD-ROM), and have the user manually install the upgraded 
software. As will be appreciated from FIG, 1, a software 
supplier 36 coupled to the PDN 32 may remotely distribute 
and install the upgraded software on the modem 16, as this 
may provide a number of operational efficiencies. While the 
downloading and installation of software within the modem 
16 via the communications link 24 may be performed 
without end-user intervention, there is a risk that the instal- 
lation of the upgraded software may be unsuccessful. In a 
worst-case scenario, the attempted upgrade may in fact place 
the modem 16 in a condition in which it cannot boot at all. 
Specifically, wherein the downloaded software is not 
executable, for example as a result of a corrupt transmission, 
and the corrupt software overwrites previously installed 
software, the modem 16 may not be revivable from a remote 
location. In such as situation, manual intervention by the 
software supplier 36 or ISP 26 may be required to return the 
modem 16 to an operational state. Where the software 
supplier has a large installed base of modems, such manual 
intervention may be prohibitively expensive. 

With a view to avoiding situations within which manual 
intervention may be required to restore functionality, and 
specifically the abilityTo^boot] to a target machine such as a 
computer systernYth^resenTinvention proposes a software 
download mechanism that prevents a target of the download 
operation from being placed in the state in which it cannot 
boot at all. In summary, the present invention teaches 
maintaining at least two^s6ftwa7e~iml^s3vithin a memory 
resource (asscciated-witha'prcrcessorof~a"computeT^^tem. 
SpecificalIyra"first-of"the-sofrware"images"is^an"image~of 
software that has been validated and is known to be execut- 
able on the target machine. A second software image is only 
validated for execution after it is known to run successfully, 
and to perform at least one predetermined task (e.g., to 
establish communication with a network device following a 
reset). The first ("old") image is retained within the memory 
resource in case the second ("new") image fails to execute. 
The present invention is advantageous in that a software 
image that is known to be executable is always maintained 
within the memory resource, so that the target device is 
never placed in a situation in which it cannot boot. 
Specifically, in the case that the second "new" software 
image is unexecutable, for whatever reason, the target 
machine may always be booted from the first "old" software 
image. 

For the purposes of the present specification, the term 
"software image" shall be taken to mean the output of a 
linker (also termed a link editor or binder) that combines 
object modules to form an executable program. The term 
"set of instructions" shall be taken to include the term 
"software image". 

While the below description describes an exemplary 
embodiment of the invention in the context of the networked 
environment 10 shown in FIG, 1, and specifically as imple- 
mented within the modem 16, it will be appreciated that the 
teachings of the present invention are applicable to a wide 
range of environments and applications. The teachings of the 
present invention are applicable to any situation or environ- 
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ment in which an upgraded or second version of a software 
program, or portion of such a program, is installed within or 
on a machine. For example, the upgrading of software 
installed on remote Internet access devices, such as x2 

5 modems, or web access devices such as WebTV, may utilize 
the teachings of the present invention. Further, the teachings 
of the present invention may be applied to facilitate reliable 
upgrading of software within machines executing Java code. 
Referring now to FIG. 3, there is illustrated an exemplary 

io memory layout that may be implemented within the 
EEPROM 44 and RAM 48 of the modem 16. Referring first 
to the EEPROM 44, a stack pointer (SP) 60 and a program 
counter (PC) 62 are stored at the lowest address within the 
EEPROM 44. The stack pointer 60 and the program counter 

15 62 are retrieved by hardware upon reset or power up of the 
modem 16, and identify the location at which the execution 
of programs stored within the EEPROM 44 is to begin. 
Adjacent the memory location at which the stack pointer and 
the program counter 60 and 62 are stored, boot code 68 is 

20 stored within the EEPROM 44. The boot code 68 comprises 
initialized data and inflate and other library routines 70, as 
well as a boot EPROM image 72. The boot code 68 
initializes the general registers of the processor 42, and 
initializes other hardware modules that allow the modem 16 

25 to setup memory and to communicate with external devices. 
Immediately below the boot code 68, a first application 
image 74 is stored within the EEPROM 44. In one 
embodiment, the application image 74 comprises a combi- 
nation of (1) an embedded, real-time operating system, such 

30 as the Vx Works operating system developed by Wind River 
Systems of Alameda, Calif, and (2) application software for 
operation of the modem 16. While the application image 74 
may in certain embodiments be executable from within the 
EEPROM 44, access to the RAM 48 is faster, and it may 

35 thus be desirable to move the application image 74 from the 
EEPROM 44 to the RAM 48, as indicated by arrow 76. The 
application image 74 may furthermore be compressed, in 
which case the application image 74 is decompressed before 
being stored within the RAM 48. The boot code 68, and 

40 specifically the inflate routine, is responsible for performing 
the above transfer and decompression operations. 

A second application image 78 is stored within the 
EEPROM 44 immediately below the first application image 
74. The second application image may comprise an updated 

45 or modified version of the operating system and application 
software embodied in the first application image 74. 
Alternatively, the first application image 74 may comprise 
an upgraded version of the operating system and application 
software embodied in the second application image 78. In 

50 any event, either one of the application images 74 or 78 may 
be designated as a "current" application image, which is 
decompressed and transferred to the RAM 48 for execution. 
In one embodiment, the current application image is iden- 
tified by a pointer value 80 stored within the NVRAM 50. 

55 The non-current application image may be a new application 
image that has been downloaded and stored in the EEPROM 
44, but not as yet validated, or an old application image for 
which the current application image is a replacement. For 
example, the pointer 80 may point to a current and execut- 

60 able "old" application image, while upgraded "new" 
software, in the form of a second application image, may be 
written to a second application image location within the 
EEPROM 44. Upon successful validation of the "new" 
application image, the pointer 80 may then be switched to 

65 indicate the "new" application image as the current appli- 
cation image for execution in place of the "old" application 
image. Any further software upgrade downloads may then 



03/01/2004, EAST Version: 1.4.1 



US 6,457,175 Bl 

5 6 

be written over the "old" application image, as the execut- application image for execution after a delay, or runs a 

ability of the new software image will have been verified, simple command loop. In the modem 16, even though the 

and the danger of rendering the machine unbootable is development boot ROM image 72 is present, it will not 

reduced. necessarily be executed during normal operation as a rom- 

As illustrated in FIG. 3, each of the application images 74 5 Start ronto^to be described below, selects an application 

and 78 includes a header portion 84 including a number of ins ea . _ _ w . 

the flags 86. In one embodiment, each of the flags 86 may Bel ° w devel °P^ nt ?• ~ m " 

represent and indicate the completion of a validation step P««* application ROM image 74 isstored, the apphcaUon 

with respect to the associated application image for ROM image 74 contammg an apphcat.on image 74A to be 

example, a sequence of flags may indicate that the applica- " copied directly to the RAM 48, as indicated by the arrow 76 

tion image 74 or 78 has the been completely written to the a ' ' *f 1 ! ,m6 ' ^ 15 •W*^. . f,ster 

EEPROM 44, that the application image has been utilized than EEPROM 44 access, apphcat.on usages typically are 

for an application boot operation at least once, that is the « e f ted 0Ul of ,he EEPR0M " D "T^V 

modem 16 has performed at least one predetermined opera- VxWorks operating system supports a ROM icsident 

tion under the direction of the application image, or that the is configuration, which may be utdizec I in the present mventaon 

!• • • e t • * II a where speed is less important than the conservation of RAM 

application image is factory installed. . m , . . - A . . 

. , , . . , . capacity. The apphcation image 74A is stored at a RAM_ 

With respect to the predetermined operation mentioned LOW__ADDRESS location within the RAM 48, and both 

above, the modem 16 may, merely for example, under the e thernet-loaded and ROM-loaded applications begin execu- 

direction of an as yet unvahdated software image, attempt to (ion al mis addfess h ^ be QOted that the boQt RQM - 

perform a sequence of steps required for the estabtehment ^ transferred from the CO mpressed boot ROM image 72, 

of a valid connection from the modem 16 to the ISP 26. ^ stQred at ram_hIGH_ADDRESS, thus providing room 

TTiese steps may involve booting the modem 16, turning on within the RAM ^ for the application image 74A t0 be 

a DSL hne, performing a set of the synchronization steps accommodated between the RAM_LOW_ADDRESS and 

witli irespectto the ISP 26, sending a predetermmed message the RA M_HIGH_ADDRESS. In one exemplary 

to the ISP 26, and receiving a response from the ISP 26. embodimenlt the modem 16 may include a second R0M that 

Upon receipt of the message from the ISP 26, a flag mds a second licalion ROM image 78, a pointer 80 in 

indicating successful completion of the predetermined me 5() indicating either the image 74 or 78 as 5eing 

operation may be toggled. a curreQt image for execution by lhe p roC essor 42. In an 

In one embodiment of the present invention, the applica- 3Q alternative embodiment of the present invention, as illus- 

tion images may conveniently be written into the EEPROM trated [ n pio. 3, a single ROM may accommodate both 

44 so that sector boundaries divide the application images 74 images 74 and 78. In either case, it should be noted that two 

and 78. This allows an application image and associated apphcation images 74 and 78 are stored and are transferable 

flags to be erased in a single step by writing all bits within t o the RAM 48 for execution purposes, 

a relevant sector to one (1). In this case, the flags may be set 35 ^ boot _ up , or starting, of the modem 16 will now be 

by setting a flag from 1 to 0 (that is, the flags are set low). deS cribed. The program counter 62 indicates an initial entry 

A more detailed description of an exemplary embodiment point following a modem 16 power-on reset. Specifically, 

of the present invention, and specifically of a system the entry point is indicated as being the romlnit routine 

memory layout and boot-up procedure of a target device, stored in romlnit.s. The romlnit routine does basic hardware 

such as a the modem 16, will now be described with 40 initialization, set up the processor stack, and branches to a 

reference to FIGS. 4 and 5. The exemplary embodiment will romStart routine in the bootlnit.c. The romStart routine is the 

be described in the context of the VxWorks operating system first C code to execute, and functions to clear memory, copy 

developed by Wind River Systems, Inc. However, the broad a current application image from the EEPROM 44 to the 

teachings of the present invention could also be imple- RAM 48, and to jump to a RAM 48 entry point. In one 

mented utilizing real-time operating systems (RTOS) such 45 embodiment, a standard VxWorks configuration positions a 

as the QNX operating system developed by QNX Software romStart routine image at either the RAM_LOW_ 

System Limited, or the Windows C.E. operating system ADDRESS or the RAM__HIGH_ADDRESS, opposite the 

developed by Microsoft Corp. of Redmond, Wash. application image 74A. Although linked to such a RAM 

The VxWorks operating system supports a wide variety of address, the romStart routine begins execution within the 

target memory configurations. One exemplary memory con- 50 EEPROM 44. Specifically, the romStart routine first calls a 

figuration is described below. It will readily be appreciated copyLong routine, and copies the romStart routine image 

that the principles described below may equally well be text and data to the RAM address. After copying the start-up 

implemented in an alternative memory configuration. Refer- code and clearing the rest of the RAM 48 to zero's, the 

ring now specifically to FIG. 4, the EEPROM 44 is shown romStart routine then decompresses the application image 

to include an initial stack pointer (SP) 60 and an initial 55 74A, and branches to it. The romStart routine is furthermore 

program counter (PC) 62. The EEPROM 44 stores a responsible for selecting which of the application images 74 

VxWorks development boot EEPROM image 72 below the or 78 to execute based on the pointer 80 stored within the 

stack pointer 60 and the program counter 62, the boot ROM NVRAM 50, the state of the images indicated by the image 

image 72 functioning to load a test version of a target headers 84, and possibly an external input such as a setting 

application via the Ethernet interface 40. The boot ROM 60 of the dip switches 82. 

image 72 is a special VxWorks application that reads in a As illustrated in FIG. 4, each of the application images 74 

link module and branches to it, restarting the target (i.e., the and 78 includes both an image header portion 84 and a 

modem 16). Besides loading a test version of an application, compressed body portion 87. Each of the application image 

the boot ROM image 72 can also be executed to set or header portion 84 includes a number of flags 86 providing 

display memory, set boot parameters, set an Ethernet MAC 65 information concerning the associated application image, 

address in the NVRAM 50, or launch to an arbitrary memory Specifically, the flags 86 may indicate whether the applica- 

address. Depending on boot parameters, it either loads an tion image is complete (that is, whether the application 
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image was successfully written into the EEPROM 44); 
whether execution of the application image has been 
attempted once; and whether the modem 16 runs success- 
fully under the application image (e.g., communicates with 
a line card within the hub 28 of the ISP 26). The image 5 
header portion 84 may also include flags 86 indicating the 
size of the image, the type of the image, and a string giving 
the software revision name. In one embodiment, an initial 
application image that is factory installed may include an 
additional flag marking the image as factory installed, and 30 
indicating that the image is expected to work, and should be 
tried first. Accordingly, the romStart routine may examine 
the image header portions 84 associated with both images 74 
and 78 to determine which of these application images is 
current. For example, the flag 86 indicating that the appli- 
cation image runs successfully will not be set for a newly 
loaded application image which has not been validated. 

FIGS. 6Aand 6B are flowcharts illustrating a method 100, 
according to one exemplary embodiment of the present 
invention, of installing a second set of instructions, in the 20 
form of an application image, within a machine, such as for 
example the modem 16. The method 100 commences at step 
102 with a reset operation, and proceeds to step 104, where 
the romStart routine selects a first application image, for 
example application image 74, as a current image to boot. 25 
This determination is made by the romStart routine with 
input from the NVRAM 50 in the form of the pointer 80 
which identifies the application image 74 as the current 
image. 

At step 106, the modem 16 performs a validation opera- 30 
tion. While this validation operation may vary from embodi- 
ment to embodiment of the present invention, in the present 
embodiment, the validation operation comprises the step of 
establishing a communication link between the modem 16 
and the ISP 26, Specifically, the establishment of the com- 35 
munication link at step 106 may include booting the modem 
16 utilizing the first application image 74 selected at step 
104, turning on a Digital Subscriber Line (DSL), synchro- 
nizing the modem 16 and ISP hardware, sending a message 
from the modem 16 to the ISP 26, and receiving a response 40 
message from the ISP 26 at the modem 16. It will however 
be appreciated that, in other applications, any number of 
other validation operations may be performed to confirm 
proper operation of the device when executing a set of 
instructions comprising any particular application image. 45 
Having established a communication link at step 106, the 
transmission of a new, second application image 78 to the 
modem 16 is commenced at step 108. The File Transfer 
Protocol (FTP) may be utilized for the transmission of the 
second application image 78 to the modem 16. For example, 50 
the second application image 78 may be propagated to the 
modem 16 from the software supplier 36 over the PDN 32 
and via the ISP 26. In the event that the second application 
image 78 is to be written to a memory location occupied by 
a third application image (e.g., an application image that was ss 
replaced by the first application image selected at step 104), 
the third application image is erased, and associated flags 86 
arc cleared, at step 110. At step 112, a packet included within 
the transmission begun at step 108 of the new, second 
application image 78 is received at the modem, and this 60 
packet is then written to the EEPROM 44 at step 114. The 
second application image 78 may be received, merely for 
example, within the modem 16 via the Ethernet interface 14 
from the LAN 14. Alternatively, the second application 
image 78 may be received into the EEPROM 44 via the UTP 65 
interface 46 via the communication link 24 from an external 
software supplier 36. Referring to FIG. 3, the second appli- 
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cation image 78 is written to a separate, distinct memory 
within the EEPROM 44, so as not to override the first 
application image 74. At decision box 116, a determination 
is made as to whether the download of the second applica- 
tion image 78 is complete. This determination is made, for 
example, by referencing indications provided by the File 
Transfer Protocol (FTP), If not, the method 100 to proceeds 
to decision box 118, wherein a determination is made as to 
whether a download failure has occurred. For example, a 
packet comprising the transmission to the modem 16 may 
have been corrupted, or not received. If a download failure 
has occurred, the method 100 then loops back to step 102, 
where the reset operation is again performed, and the 
modem 16 boots using the first image 74. Alternatively, 
should no download failure 118 be detected at decision box 
118, the method 100 loops back to step 112, where a further 
packet of the transmission of the new application image 78 
is received. Assuming no download failure, the method 100 
loops through steps 112-118 until the complete second 
application image 78 has been written into the EEPROM 44. 

Once it is determined that decision box 116 that the 
transmission and reception of the second application image 
78 has been completed, the method 100 proceeds to step 
120, as indicated in FIG, 6B, where the second application 
image 78 is marked as complete. Referring now to FIG, 7, 
an exemplary second application image 78 is illustrated. The 
application image 78 includes a header portion 84 including 
a number of flags 86, namely; 

1. A "complete" flag 200; 

2. A "tried" flag 202; 

3. An "okay" flag 204; and 

4. A "factory installed" flag 206. 

The second application image 78 may be marked as 
complete at step 120 by setting the complete flag 200 to a 
predetermined state. The setting of the complete flag 200 
indicates that the associated second application image 78 is 
complete and has been completely and successfully written 
into the EEPROM 44. At step 122, the modem 16 is then 
again subject to a reset operation. At step 124, the second 
application image 78 is selected for the boot-up operation. 
This selection may be performed by temporary indicating 
the second application image 78 as the current application 
image within the NVRAM 50. At step 126, the second 
application image 78 is marked as "tried". For example, the 
step 126 may include setting the tried flag 202 to a prede- 
termined state. At step 128, the modem 16, under the 
direction of the set of instructions comprising the second 
application image 78, attempts to perform a validation 
operation to validate operation of the modem 16. In one 
exemplary embodiment, the validation operation may again 
comprise the establishment of a communication link 
between the modem 16 and the ISP 26 in the manner 
described above with reference to step 106. At decision box 
130, a determination is made as to whether the communi- 
cation link has been established before a timeout period. For 
example, should a "timeout" timer (not shown) within the 
modem 16 expire, the condition proposed at decision box 
130 will not be met, in which case the method 100 returns 
to step 102, where the modem 16 is reset. 

On the other hand, should a communication link the 
successfully established between the modem 16 and the ISP 
before the timeout, the second application image 78 is 
marked as valid at step 132, for example, by setting the OK 
flag 204 to a predetermined state. Accordingly, the flags 200, 
202, and 204 will each have been sent to a predetermined 
state to indicate the second application image 78 as valid. 
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The setting of all three flags 200, 202 and 204 to the 
predetermined state marks the associated application image 
as a validated boot-up image, and accordingly the pointer 80 
within the NVRAM 50 will retain an indication of the 
application image selected at step 124 as the boot-up image. 
At step 134 the modem 16 is again subject to a reset 
operation, whereafter the second application image 78 is 
selected as the boot-up image at step 136 in accordance with 
the indication provided by the pointer 80, and on account of 
the flags 200, 202, and 204 for the second application image 
78 indicating the second application image 78 as being 
successfully validated. 

Turning now to FIG. 8, there is illustrated a flowchart 
illustrating a method 140, according to an exemplary 
embodiment of the present invention, of determining 
whether an application image is valid by the inspection of 
various flags 86 included within a header portion 84 asso- 
ciated with the relevant application image. The method 140 
may be executed at any one of the steps of method 100 that 
require the selection of an application image. Specifically, 
the step of selecting an application image for a boot-up 
operation may be performed by examining an application 
image indicated by the pointer 80, and then by determining 
whether the application image is valid utilizing the method 
140. 

The method 140 commences at step 142 where the 
various flags 86 included within the header portion 84 are 
read. At decision box 144, a determination is made as to 
whether the complete flag 200 (as illustrated in FIG. 7) 
indicates that the application image is complete. 
Specifically, a determination may be made as to whether the 
complete flag 200 has been set to a logical zero (0). If so, a 
further determination is then made at decision box 146 
whether the image has previously been tried. Specifically, 
the tried flag 202 is examined to determine whether it has 
been set, for example, to a logical zero (0). If the image has 
not been tried (i. e., is newly installed but not yet validated), 
step 156 marks the image "tried" and proceeds to step 150 
indicating that the image is to be executed. If the image has 
been tried as indicated by flag 202 execution proceeds to 
decision box 148. Decision box 148 makes a final determi- 
nation based on the OK flag 204. Specifically the OK flag 
204 may be examined to determine whether it has been set, 
for example, to a logical zero (0). If the OK flag 204 is set, 
the image has previously successfully performed a prede- 
termined validation operation and hence is valid for execu- 
tion. The method 140 accordingly recognizes the image as 
valid at step 150 and terminates at step 152. If the OK flag 
204 is not set the method 140 determines that the validation 
has been attempted but failed, recognizes the image as 
invalid at step 154, and terminates at step 152. 

The method 140 proposed by the present invention is 
advantageous in that it does not permit a target device to 
view an application image as being valid, and therefore 
selectable as a current and executable application image, 
unless the application image is confirmed as being com- 
pletely written to a memory resource within the target device 
and also successfully performs a validation function. During 
the writing and validation steps of a "new" or second set of 
instructions in the form of a second application image, an 
"old" or first set of instructions in the form of a first 
application image is not overwritten, and maintained 
executable, so as to ensure that the target device is not 
rendered unbootable as a result of the loading of the second 
set of instructions. The invention is advantageous in that the 
frequency of service calls by personnel to target devices, 
which may comprise embedded devices in inaccessible 
locations, may be reduced. 
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Returning to FIG. 2, the processor 42, EEPROM 44, and 
RAM 48 are each shown to include a sequence of machine - 
readable instructions 160, or at least a portion of such a 
sequence of instructions, that when executed by the 

5 machine, such as for example the modem 16, cause the 
machine to perform any one of the steps described above in 
the specification, and specifically the steps described with 
reference to the flow charts shown above. Accordingly, for 
the purposes of the specification, the term "machine- 

10 readable medium" shall be taken to include any medium that 
is capable of storing or otherwise accommodating a 
sequence of instructions for execution by a machine, and 
that cause the machine to perform the methodologies of the 
present invention. Accordingly, the term "machine-readable 

15 medium" shall be taken to include, but not be limited to, 
solid-state memories, optical and magnetic disks, and 
carrier-wave signals. For example, the instructions for per- 
forming the methodologies of the present invention may be 
propagated to a target machine via a communication link and 

20 be encoded within a suitable carrier-wave signal. 

Thus, a method and apparatus for installing a second set 
of instructions within a machine, the machine including a 
memory resource storing first and second set of instructions, 
have been described. Although the present invention has 

25 been described with reference to specific exemplary 
embodiments, it will be evident that various modifications 
and changes may be made to these embodiments without 
departing from the broader scope and spirit of the invention. 
Accordingly, the specification and drawings are to be 

30 regarded in an illustrative rather than a restrictive sense. 
What is claimed is: 

1. A method of installing a second set of instructions 
within a machine, the machine including a memory resource 
storing a first set of instructions, the method including: 
35 executing the first set of instructions; 

loading a second set of instructions into the memory 
resource from a remote device, while maintaining the 
first set of instructions within the memory resource; 
^ validating the second set of instructions, the validating 
including determining whether the machine, operating 
under the direction of the second set of instructions, 
successfully performs a predetermined function; and 
if the second set of instructions is valid, indicating the 
45 second set of instructions as executable in place of the 
first set of instructions, 
wherein the predetermined function includes establishing 
communications between the machine and the remote 
device under direction of the second set of instructions, 
so 2. The method of claim 1 wherein the validating includes 
determining whether the second set of instructions is com- 
pletely stored within the memory resource. 

3. The method of claim 2 wherein the validating includes, 
subsequent to the determination of whether the second set of 

55 instructions is completely stored within the memory 
resource, resetting the machine for execution of the second 
set of instructions. 

4. The method of claim 1 wherein the validating includes 
determining whether execution of the second set of instruc- 

60 tions has been previously attempted. 

5. The method of claim 1 wherein the machine is a 
modem, and wherein the validating includes determining 
whether the modem establishes a communication link with 
the remote device. 

65 6. The method of claim 5 wherein establishing of the 
communication link includes liming out a communication 
operation after a predetermined time threshold. 
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7. The method of claim 1 including, subsequent to the 
performance of the predetermined function, resetting in the 
machine for execution of the second set of instructions. 

8. The method of claim 1 including loading the second set 
of instructions into the memory resource subsequent to s 
commencement of the execution of the first set of 
instructions, while maintaining the first set of instructions 
within the memory resource. 

9. The method of claim 8 wherein the loading includes 
loading an object code image into a read-only memory. 10 

10. The method of claim 9 wherein the loading of the 
object code image includes loading a compressed object 
code image. 

11. The method of claim 8 wherein the loading includes 
downloading the second set of instructions to the memory 15 
resource from a remote location. 

12. The method of claim 11 wherein the executing of the 
second set of instructions includes decompressing an object 
code image and transferring the object code image from a 
read-only memory to a random access memory. 20 

13. The method of claim 1 wherein the indicating includes 
setting a pointer to indicate the second set of instructions for 
default execution. 

14. The method of claim 1 including resetting the 
machine, and executing the second set of instructions. 25 

15. A machine comprising: 

a memory resource to store a first and second set of 
instructions; and 

logic to execute the first set of instructions, to load the 
second set of instructions into the memory resource 30 
from a remote device while maintaining the first set of 
instructions within the memory resource, to validate the 
second set of instructions by determining whether the 
machine, when executing the second set of instructions, 
successfully performs a predetermined function, and to 35 
indicate the second set of instructions as executable in 
place of the first set of instructions, 

wherein the predetermined function includes establishing 
communications between the machine and the remote 4Q 
device under direction of the second set of instructions. 

16. The machine of claim 15 wherein the logic determines 
whether the second set of instructions was completely 
written to the memory resource of the machine. 

17. The machine of claim 15 wherein the logic determines 45 
whether execution of the second set of instructions has 
previously been attempted. 

18. The machine of claim 15 wherein the logic determines 
whether a communication link is established between the 
machine and a remote device. 5Q 

19. The machine of claim 18 wherein the logic determines 
whether the communication link is established within a 
predetermined time-out period. 

20. The machine of claim 15 including an interface via 
which the second set of instructions is loaded into the 55 
memory resource subsequent to the commencement of 
execution of the first set of instructions, while maintaining 
the first set of instructions within the memory resource. 

21. The machine of claim 20 wherein the interface facili- 
tates the loading of the second set of instructions into the 6Q 
memory resource from the remote location. 

22. The machine of claim 15 wherein the memory 
resource comprises a read-only memory, and the second set 
of instructions comprises an object code image. 
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23. The machine of claim 15 including a pointer to 
indicate either the first or the second set of instructions as a 
default set of instructions for execution by the machine. 

24. The machine of claim 23 wherein the logic sets the 
pointer to indicate the second set of instructions for default 
execution after validating the second set of instructions. 

25. The machine of claim 24 wherein the pointer com- 
prises a memory resource storing a flag. 

26. A machine-readable medium storing a sequence of 
instructions that, when executed by a machine, cause the 
machine to: 

load a replacement set of instructions from a remote 
device, while executing an existing set of instructions; 

validate the replacement set of instructions by determin- 
ing whether the replacement set of instructions 
executes to establish communications with the remote 
device; and 

if the second set of instructions is valid, then indicate the 
second set of instructions as executable by the machine 
in place of the first set of instructions. 

27. A method to install replacement software, the method 
including: 

downloading the replacement software from a provider to 
a target device, the replacement software to replace 
existing software stored by the target device; and 

causing execution of the replacement software by the 
target device so as to validate the replacement software, 

wherein the replacement software is validated upon detec- 
tion of a successful establishment of communications 
between the target device, operating under direction of 
the replacement software, and the provider. 

28. The method of claim 27 including downloading the 
replacement software to the target device subsequent to 
commencement of execution of the existing software, while 
maintaining the existing software at the target device. 

29. The method of claim 27 wherein the downloading of 
the replacement software includes downloading an object 
code image into read-only memory of the target device. 

30. The method of claim 29 wherein the downloading of 
the object code image includes downloading a compressed 
code image. 

31. The method of claim 29 wherein the causing of the 
execution of the replacement software includes decompress- 
ing the object code image, and transferring the object code 
image from the read-only memory to a random access 
memory. 

32. A machine- readable medium storing a sequence of 
instructions that, when executed by a source machine, cause 
the source machine to perform the operations of: 

downloading replacement software from a provider to a 
target device, the replacement software to replace exist- 
ing software stored by the target device; and 

causing execution of the replacement software by the 
target device so as to validate the replacement software, 

wherein the replacement software is validated upon detec- 
tion of a successful establishment of communications 
between the target device, operating under the direction 
of the replacement software, and the provider. 

* * * * * 
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SMART FLASH module for reprogramming the reprogrammable read only 

memory. ATandonTaccess" memory stores a new pFogram} 

This application is a continuation application of U.S. imageTfor^the reprpgr^mable read only memory^ A 

application Ser. No. 08/336,043 filed Nov. 4, 1994, now p go c e s s p r, which s ends Wd~ Tec e i v e s network^ 

abandoned. 5 'communications, confirms that roe_ new program image is 

compatible with the configuration information in the current 

BACKGROUND OF THE INVENTION network information file block, and executes the software 

1 Field of the Invention reprogramming module so as to reprogram the reprogram- 
mable read only memory with the new program image in a 

The present invention concerns a reprogrammable net- 3Q case where compatibility * confirmed. 

work communication device which communicates on a _ c , ... ifi . , • 4 . 

. w . . . . t . * t . In preferred embodiments of the present invention, the 

network. More particularly, the present invention relates to — - . \ i • c c . 

f, , • • j ■ ... new proeram image includes a new network information nle 

a reprogrammable network communication device which ^ — , 1 — , — j— : — ; f 

/..... j ■ t_ -*>cr~\. block, and the processor replaces board -invan ant portions ot 

confirms that it is being rep rogrammed with a ✓compatible S . ' -v___^_» 7 r— ■-. - — 

a"e before it allows re ro rammin to occur — — new networ ^ information file block with corresponding 

•maage^ e ore i a ows reprogramming o occur. 15 p 0rt - Qns 0 f ^ ^j-j^m network information file block before 

2. Incorporation by Reference execution of the software module. In particularly preferred 
U.S. patent application Ser. No. 07/978,369, entitled embodiments of the present invention, the configuration 

"Method And Apparatus For Interfacing A Peripheral To A information in the current network information file block 

Local Area Network", now U.S. Pat. No. 5,611,046, is includes a MAC address, network media configuration 

hereby incorporated by reference. 20 information, host interface configuration information, prod- 

3. Description of the Related Art uct configuration information, processor configuration infor- 
In recent years, as local area networks (LANs) grow more matioa and memory confi^atjonjnfio^ 

complex, it has become common to^rrde^twoTkcoln} rs^rconfirms co^npatibiUtyof „ the^new programjmage by 

munication devicesAwith the newest tecmwlogy~£vIilable. comparing the configuration informaUon in" the current net- 

'Sucrupgrades are~easiest to perform over the LAN. For 25 Vf9& ^information. file block with configuration information) 

example, a network administrator can remotely alter a ^ e ne ^ net ™ bri: information file block. ^ 

(firmware" image on_ a„ network communication device by } This brief summary has been provide so that the nature of 

downloadihg^eWdata tcnhc„device,.which then reprograms^ the invention may be understood quickly. A more complete 

itself witfthe-new finnware"imageT3 understanding of the invention can be obtained by reference 

A typical personal computer (PC)"bnto which a network 30 to the following detailed description of the preferred 

administrator may log, however, maybe connected to more embodiment thereof in connection with the attached draw- 
than one-LAN. For example, a PC may be connected to both 

an Ethernet LAN and to a Token-ring LAN, and may nFsrRTPTTON OF THF DRAWINGS 

function as the netw^k^adrnm_istratorJo_r both networks. 35 BRIEF DESCRIPTION OF THE DRAWINGS 

Each of the (LANs may in turn be connected to several FIG. 1 is a diagram of a local area network and wide area 

reprogrammable network communication devices} Thus, in network to which a network board is coupled. 

such" a structure, there are multip]e3^vice^ which the FIG. 2 is a cut-away perspective view of the network 

network administrator can potentially reprogram, and there board fitted int0 a Canon LBP 12 60 laser printer. 

is therefore a possibilityjhaMhe ^network adrn^mis^ 40 piG 3 fa a block di M the netWQrk board 

m^t madve^lejnly^gram^ coupled between a printer and a local area network, 

incompatible image. ^ . . . . 

— =r 7: r 1 ^ 1 ,,, . . FIG- 4 is a diagram showing the physical layout or 

The resu Is of downloading an incompatible image can be . .u . 1 u j 

, . j-t . . r f. , 1 j • . components on the network board, 

devastating. For example, u the network administrator erro- r 

neously downloads a Token-ring image to a card connected 45 FIG - 5 * a drawia 8 of a face P late for the network board - 

to an Ethernet LAN, and that card then reprograms itself FIG. 6 is a functional block diagram of the network board. 

with the Token-ring image, it will no longer be able to FIG. 7 is a diagram showing examples of several software 

communicate on an Ethernet LAN at all. This means that the modules that may be stored in the flash EPROM. 

card could not even be reprogrammed over the LAN — it is, FIG. 8 is a block diagram of an arrangement used to 

quite literally, a "dead" board as far as the Ethernet LAN is 50 determine which connector is connected to the network. 

concerned. Other incompatibilities, such as, for example, FJG 9 fe a flowcharl showing how to detect which 

incompatibilities in the host interface configuration, product con nector is connected to the network. 

configuration, processor configuration and memory mQ 1Q {g a flow ^ shQwi ^ ioQ Qf a 

configuration, can result in dead boards. PRETASK software module. 

SUMMARY OF THE INVENTION 5S FIGS. 11(a) through 11(d) are diagrams showing possible 

^ t ...... 1 relationships of various network software modules. 

To prevent such disastrous results in the case where a wjr , . , , , . n „ 

C network-communication"d^ice-is- downloaded with an^ „ U FIG - X \ 15 \ block showing a PC connected to a 

rSncompatibleJmage, the present invention~ensures that Ihe Ethernel local area network and a Token-ring local area 

"downloaded image is compatible before the actual repro- 60 network - 

gramming occurs. 13 is a diagram showing contents of a network 

In one aspect of the present invention, a reprogrammable information file block used for storing configuration infer- 

network communication device which communicates on a mation. 

network includes CJeprogr^nmable^read^only memory^ FIG- 14 is a flowchart showing reprogramming of flash 

whieffs^res ^current program image;, a current network 65 EPROM. 

information file block^cbntaining configuration information FIG. 15 is a block diagram of a memory arbitration 

for the network communication device, and a software device. 
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FIG. 16 is a block diagram of one preferred construction Server" by Novell, March 1991 edition, Novell Part No. 

of a shared memory arbiter in the arbitration device. 100-000892-001. 

FIG. 17 is a diagram showing the timing of signals Briefly, file server 106 acts as a file manager, receiving, 

provided to the arbitration device. storing, queuing, caching, and transmitting flies of data 

nr 1C • „ • fu^nfi™,,,;^ n fch,™^ 5 between LAN members. For example, data files created 

FIG. 18 is a diagram showing the configuration or shared . , ... VA -,- — -r^T— -^Jj. .... 

respectively at PCs 103 and 104 may be routed to file server 

' . . , , . 106 which may order those data files and then transfer the 

FIG. 19 is a flowchart showing the operations involved in rf ^ ed daU mes tQ pdm er;109 upon commTnd from print 

writing into shared memory. serveF108~ ~~~~ 

FIG. 20 is a flowchart showing operations involved in 10 PCs 103 and 104 may each comprise a standard PC 

reading from shared memory. capable of generating data files, transmitting them onto LAN 

FIGS. 21(a) through 21(c) show various alternatives for 100, receiving files from LAN 100, and displaying and/or 

configuring shared memory. processing such files. However, while personal computer 

FIG 22 is a block diagram of a serial port. equipment is illustrated in FIG. 1, other computer equipment 

FIGS. 23(a) and 24(a) are flowcharts showing operations 15 ™? also be ia ^> as app 5^' e *° the , netWOrk Softwa u re 

.j. 7 .., ., !L • being executed. For example, UNIX workstations may be 

involved in receiving and sending serial communications f „ vnv r . , J , 

..... included in the network when UNIX software is used, and 

over the serial port. , . , , . . / , 

. _ those workstations may be used in conjunction with the 

FIGS. 23(b) and 24(b) are diagrams showing the timing of illuslrated PCs under appropriate circumstances, 

signals in the serial receive and send modes. 2Q XyDicallV) a lan such as lan i0 0 services a fairly 

DETAILED DESCRIPTION OF THE localized * roup fl of UserS su ? h a g ™ P of ^ 00 0DC floor 

PREFERRED EMBODIMENT or c ° t ntl f ous floors t ^ a building. As users become more 

remote from one another, for example, in different buildings 

In its most preferred form, the present invention is embod- or different states, a wide area network (WAN) may be 

ied in a network board (or "NEB") which provides 25 created which is essentially a collection of several LANs all 

hardware, software and firmware solutions for making a connected by high speed digital lines, such as high speed 

network peripheral, such as a printer, an intelligent, inter- integrated services digital network (ISDN) telephone lines, 

active network member, capable not only of receiving and Thus, as shown in FIG. 1, LANs 100, 110 and 120 are 

processing data from the network, but also of transmitting to connected to form a WAN via modulator/demodulator 

the network significant amounts of data about the peripheral 30 (MODEM)/transponder 130 and backbone 140, which is 

such as detailed status information, operational parameters simply an electrical connection between several buses. Each 

and the like. It is also possible to use the invention in other LAN includes its own PCs, and each ordinarily includes its 

networked peripherals such as scanning, facsimile, copier, own file server and print server, although that is not neces- 

image processing and other such peripherals. Integration of sarily the case. 

such hardware, software and firmware with the peripheral 35 Thus, as shown in FIG. 1, LAN 110 includes PCs 111 and 

eliminates the need to dedicate a personal computer to act as 112, file server 113, network disk 114, print server 115 and 

a peripheral server. printers 116 and 117. LAN 120, on the other hand, includes 

[Network Architecture] only PCs 121 and 122. Via WAN connections, equipment in 

FIG. 1 is a diagram showing the present invention incor- any of LANs 100, 110 and 120 can access the capabilities of 

porated into a NEtwork Board (NEB) 101 coupled to a 40 equipment in any other of the LANs, 

printer 102 having an open architecture. NEB 101 is coupled PC 104 may be embedded with an RPRINTER software 

to local area network (LAN) 100 through a LAN interface, program, and as such may exert limited control over network 

for example, an Ethernet interface 10Base-2 with a Coax peripherals. The RPRINTER program is an MS-DOS 

connector or lOBase-T with an RJ-45 connector. terminate-and-stay-resident ("TSR") program which allows 
f Plural per^nalncomyuters (PCs), such as PCs 103 and>45 users to share printer 105 connected to PC 104 while at the 

l(W^aic„also_cp.Mecte.d„lo_.L^,,100, and under control of same time allowing PC 104 to execute other non -print 

the network operating system these PCs are able to com- applications. RPRINTER is a relatively unintelligent pro- 

municate with NEB 101. One of the PCs, such as PC 103, gram that does not have the ability to search printer queues 

may be designated for use as the network administrator. A for work. RPRINTER gets its work from print server 108 

PC may have a printer connected to it, such as printer 105 50 running elsewhere in the network. Because it communicates 

connected to PC 104. with the attached printer over the printer's parallel port, PC 

Also connected to LAN 100 is file server 106 which 104 running RPRINTER is able to obtain only limited status 

manages access to files stored on a large capacity (e.g., 10 information from printer 105 and to return that status 

gigabyte) network disk 107. A print server 108 provides information to print server 108 over LAN 100. From a 

print services to printers 109 and 110 connected to it, as well 55 control standpoint, RPRINTER allows stopping of a print 

as to remote printers such as printer 105. Other unshown job (when, for example, the printer is out of paper or 

peripherals may also be connected to LAN 100. off-line) and little more. Some printers include RPRINTER 

In more detail, the network depicted in FIG. 1 may utilize features by offering internal or external circuit boards that 

any network software such as Novell or UNIX software in provide the same limited features of the RPRINTER TSR 

order to effect communication among the various network 60 program running in a personal computer, 

members. The present embodiments will be described with Print server 108 is capable of exercising more significant 

respect to a LAN utilizing Novell NetWare® software, control over LAN peripherals but requires a dedicated PC 

although any network software could be used. A detailed which cannot be used for any other task. Print server 108, 

description of this software package may be found in which may itself be a PC, has the ability to service multiple 

"NetWare® User's Guide" and "NetWare® Supervisor's 65 user-defined print queues, perform dynamic search queue 

Guide", published by M&T Books, copyrighted 1990, incor- modification, and provide defined notification procedures 

porated herein by reference. See also the "NetWare® Printer for exception (failure) conditions and status and control 
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capabilities, and can control both local printers 109 and 110 
(that is, printers physically connected to print server 108) 
and remote printers. Local printers 109 and 110 can be 
connected to either serial or parallel ports, and the remote 
printers, such as printer 105, are printers running elsewhere 
in the system which print server 108 controls through 
R PRINTER software. 

Print server 108 can control many local or remote printers 
and can request print information from many file server 
queues. However, there are several drawbacks to relying on 
print server 108 to control network printing services. A first 
drawback is that multiple printer streams must all be fun- 
nelled through a single network node. This can become a 
bottleneck. A second drawback is that for the most efficient 
operation, the printers should be connected to the print 
server locally, like printers 109 and 110. This can be an 
inconvenience for users since it requires the printers to be 
clustered around print server 108 and also requires users to 
travel to those clustered printers. A third drawback is that if 
the controlled printers are remote, as in the case of printer 
105 which is serviced by RPRINTER, then print data must 
make several trips, first from file server 106 to print server 
108, and then from print server 108 to the printer running 
RPRINTER. This is inefficient. 

A fourth drawback is the limited amount of printer status 
and control information offered through print server 108. It 
has already been stated that RPRINTER does not allow for 
much more than rudimentary status information such as "out 
of paper" and "offline". Print server 108 does not offer more 
than this because it was designed with consideration of the 
^limitations of the personal computer parallel port. 
\[The Network Board]/ 

Installation^ NEB 101 into printer 102 provides many 
advantages over the network peripheral control entities 
discussed above, in that it allows printer 102 to become an 
intelligent, interactive network member. 

As shown in FIG. 2, NEB 101 is preferably housed in an 
internal expansion I/O slot of printer 102, which in a 
preferred embodiment of the present invention is a Canon 
LBP 1260 laser printer.<ftis"m akes NE B101^hTembe<lded3 



10 



15 



20 



25 



30 



35 



101, which is constructed from a printed circuit board 101a 
on which is mounted face plate 101b which allows for 
network connections, is connected via connector 170 to 
printer interface card 150. As described below, printer 
interface card 150 directly controls the print engine in 
printer 102. Print data and printer status commands are fed 
to printer interface card 150 from NEB 101 via connector 
170, and printer status information is obtained from card 150 
also via connector 170. NEB 101 communicates this infor- 
mation onto LAN 100 via the network connectors on face 
plate 1016. At the same time, printer 102 can also receive 
print data from conventional serial port 102a and parallel 
port 102b. 

FIG. 3 is a block diagram depicting electrical connection 
of NEB 101 to printer 102. NEB 101 is directly connected 
to LAN 100 via a LAN interface, and to printer 102 via 
printer interface card 150. In a preferred embodiment of the 
invention, the printer interface card 150 is a Peerless LBP- 
860/1260-External Standard I/O Board Interface, available 
from Peerless Systems Corp., the details of which can be 
found in the Peerless Standard I/O Interface Design 
Specification, revision 2.07a, Peerless Systems Corp., May 
10, 1994. The board includes an Intel 80960KB-20 micro- 
processor 151. Although it is a 32-bit machine, micropro- 
cessor 151 accesses data to and from NEB 101 are in 2 byte 
wide (16-bit) transfers via a shared memory 200 arranged on 
NEB 101. Microprocessor 151 also communicates with print 
engine 160 which actually drives the printing mechanism. 
[NEB Physical Layout] 

FIG. 4 shows the dimensions of a preferred embodiment 
of NEB 101 and the physical layout of the major compo- 
nents thereof. The NEB card is 3.93 inches by 5.60 inches. 
NEB 101 includes a printer interface card connector 170 
(which in the case of the Peerless printer interface card is an 
80-pin connector) that couples to the printer interface card 
and face plate 300 having connectors 301 and 302 that allow 
connection to LAN 100. The face plate also includes 4 status 
light emitting diodes (LEDs) 303-306. Arranged on the 
NEB card are transceiver 171, crystal oscillator 172, micro- 



^network-node'havingltKe processing and~data storage~fea-\40 processor 173, arbiter control logic 400, fiasji erasable 
M J , - rvr -"-' r x - - " programmable_rej^~only^^ 

^random -liccess memory (DRAM) 175; ; first static random-, 
Caccess memory (SRAMy200, seconTSRXM~176, network 
and NEB controflogic 500, and serial port connector 600. 
Each of these components will be discussed in greater detail 
below. 

FIG. 5 depicts a more detailed view of face plate 300, the 
dimensions of which are 4.56 inches by 1.28 inches. As 
stated above, NEB 101 couples to LAN 100 through con- 
nectors 301 and 302. Preferably, connector 301 is an RJ-45 
connector capable of accepting a lOBase-T connection, 
while connector 302 may be a simple coax connector 
capable of accepting a 10Base-2 connection. Status LED 
303 is lit when NEB 101 is transmitting data over LAN 100, 
and status LED 304 is lit when NEB 101 is receiving data 
from LAN 100. Status LED 305 is lit when RJ-45 connector 
301 is connected to LAN 100, while status LED 306 is lit 
during self-test diagnostics of NEB 101. Mounting holes 
307 accept crews for fixing NEB 101 to printer 102. 
eo^fNEBJ^Wtecture]^; 

Thearchitecture of NEB 101 is shown in FIG. 6. Power 
for all circuits is supplied to NEB 101 from a +5V power 
source 177. +5 V power is also provided to power converters 
178 and 179. Power converter 178 provides -9V power to 
transceiver 171, while power converter 179 provides +12V 
power to flash EPROM 174 for "flashing" (i.e., reprogram- 
ming of the EPROM). 



tures de^ribed,below~ 

The architecture of NEB 101 provides an advantage in 
that it has unique support features for administration and 
management of large, multi-area WAN networks. These 
support features could include, for example, printer control 
and status monitoring from a remote location on the network 
(such as from the network administrator's office), automatic 
management of printer configuration after each print job to 
provide a guaranteed initial environment for a next user, and 
printer logs or usage statistics accessible across the network 
for characterizing printer workload and scheduling toner 
cartridge replacement. 

An important parameter in the NEB design is the ability 
to access the printer control state from NEB 101 through a 
bidirectional interface, here a shared memory, although 
other bidirectional interfaces such as SCSI interfaces are 
also possible. This allows printer console information to be 
exported to NEB 101 or to an external network node so as 
to allow programming of many useful support functions. 
Blocks of print image data and control information are 
assembled by a microprocessor on board NEB 101, they are 
written into the shared memory, and they are then read by 
printer 102. Likewise, printer status information is trans- 
ferred from printer 102 to the shared memory, from where it 
is read by the NEB microprocessor. 

FIG. 2 is a cut-away perspective view showing installa- 
tion of NEB 101 into printer 102. As seen in FIG. 2, NEB 



45 



50 



55 



65 



03/01/2004, EAST version: 1.4.1 



6,023,727 



8 



10 



35 



20 



25 



Network and NEB control logic 500 is preferably a single 
144-pin application specific integrated circuit (ASIC) that 
includes a network controller 510 and NEB control logic 
520. Network controller 510 is an NCR macro-cell compat- 
ible with National DP83902A"ST-NIC" Ethernet controller, 
the details of which can be found in National Semiconduc- 
tor's Local Area Networks Databook, National Semicon- 
ductor p/n 400055, National Semiconductor, 1993. Network 
controller 510 is designed to interface with CSMA/CA-type 
(carrier sense multiple access with collision detection) local 
area networks. 

Network controller 510 connects with RJ-45 connector 
301 directly and with coaxial connector 302 through trans- 
ceiver 171, which is preferably a National Semiconductor 
DP8392 coaxial transceiver interface, the details of which 
can also be found in National's Local Area Networks 
Databook. Network controller 510 is also coupled to an 8KB 
SRAM 176 that is used as an input/output packet buffer for 
Ethernet data. This memory should preferably have an 
access time of about 70 ns or less. 

NEB control logic 520 provides an interface between 
network controller 510, microprocessor 173, and memory 
devices EPRON4 174 and DRAM 175. NEB control logic 
520 also inteTfaceswi th non -volatil e rand om access memory 
(NVRAM)~180, which is a 256 byte serial electrically 
(erasable/programmable memory usedToTinitialization dataj 
storage during power cycling of printer 102 whicrThouses 
NEB 101. Network and printer configuration parameters are 
written into NVRAM 180 when tj^prkiter(is"firsf installed | 
(onto~thenetwork to allow" NEB software Jo recover_the_30 
(installation parameters after printer power has'beeri cycledA 
( 'Off and on.^v ~ ™~ ~~ — 

NEB control logic 520 also coupes with serial port 
connector 600, which comprises-a receive^ata pin 601 and 
^Fransmit data pin 602 that can' respectively receive and 
transmit serial data streams for debugging purposes. NEB 
control logic 520 senses data present at the receive data line 
and samples the serial bits at regular intervals, in a manner 
that will be discussed in greater detail below. 

The central controller of NEB 101 is microprocessor 173, 
preferably an Intel 80C188EA-20 8-bit processor, the details 
of which can be found in the 80C186EA/80188EA User's 
Manual, Intel p/n 270950-001, Intel Corp. This processor is 
an 8-bit processor_witr£ jlirect memory access (DMA), 
(interrupts,''' timers, "and a DRAM refresh "'coh'trbh Other 
microprocessors, such as an AMD 80C 188-20 8-bit 
microprocessor, might alternatively be used. 256 KB flash 
EPROM 174 and 512 KB DRAM 175 are coupled to 
microprocessor 173 via NEB control logic 520, while 32 KB 
SRAM 200 (which is shared with printer interface card 150) 
is coupled with microprocessor 173 via arbiter control logic 
400. A 40 MHz, 50 ppm crystal oscillator 172 provides the 
microprocessor with a clock signal that is wholly separate 
from and asynchronous with the clock signal provided to 
microprocessor 151 on printer interface card 150. 55 

Microprocessor 173 executes instructions in flash 
EPROM 174, which stores control firmware and printing 
application software (After power-oh self-te^(TOS15,-Code^ 
is selectively moved^6~the higher performance 512 KB 
DRAM 175, which should preferably have an access time of 60 
about 80 ns, for actual executionfFlash EPROM 174 can be 
preprogrammed, or "flashed", from LAN 100, as discussed^ 
-below. 

FIG. 7 illustrates several examples of blocks of code, or 
modules, that are stored in flash EPROM 174. The XPL 65 
module provides a standardized interface between printer 
102 and NEB 101. MLID (Multi Link Interface Driver) is a 



piece of Novell code (Media Support Module, or MSM) 
linked together with a piece of customized code (Hardware 
Support Module, or HSM) that is the lowest level of network 
connection, while LSL (Link Support Layer) is a piece of 
Novell code that acts as a multiplexer between the low level 
MLID and the several protocol stacks above it. CNETX is 
customized code that turns local DOS-like function calls 
into network function calls, providing file functions like 
OPEN, READ, WRITE and CLOSE. 

The PRETASK module is responsible for identifying 
what frame types are associated with the various possible 
protocol stacks, as described below. Because NEB 101 
supports multiple protocol stacks, this module exists as long 
as NEB 101 is running. 

Noveirs IPX/SPX protocol stack is contained in flash 
EPROM 174, and is supported by SAP, or Service Adver- 
tising Protocol. SAP is a Novell concept that allows devices 
to register themselves into the file server's bindery, which 
lists active and inactive network entities. Because print 
servers are a special kind of bindery item, SAP registers 
NEB 101 via CPSOCKET, and if NEB 101 is configured as 
a print server, SAP also registers the print server with the 
NetWare bindery. 

CPRINTSERVER is a custom implementation of a Novell 
print server application. This module provides self- 
generated print banners, user notification of completion and 
exception status, and transmission of print data and status 
commands to the print engine. This differs from the Novell 
print server in that CPRINTSERVER is dedicated to driving 
the local printer (i.e., printer 102 in which NEB 101 is 
housed) and cannot drive any remote RPRINTERs. This 
program owns the print data channel for the duration of a 
print job. RPRINTER is a custom implementation of a 
Novell RPRINTER print application. This module is a slave 
application that is sent data by a Novell print server appli- 
cation elsewhere on LAN 100. 

The TCP/IP protocol stack has User Datagram Protocol 
(UDP), Reverse Address_Resolution PrqtocolJRARP) and 
<^Bc<rtP^upport-within. 11^ 
40 Yorthe TCP/IP task, whileTIMERTICK lTSeTimerlick for 
UNIX TCP/IP network tasks. LPRINTSERVER is the TCP/ 
IP print server application, and also owns the print data 
channel for the duration of a print job. 

The CPSOCKET program runs for all protocol stacks. 
[The program responds" to requests for "connect ion; ^requests J 
ffor data downloadrjor requests for services from remotej 
utilities, and provides status and control to other tasks via~^ 
interprocess communication. Because CPSOCKET typi- 
cally owns the status and control channel between NEB 101 
and printer 102, it is the only task that has the ability to 
obtain printer status via the status channel. CPSOCKET is 
responsible for the network connection and packet contents 
between the Novell -oriented status and control utilities 
(CPNET), or between the UNIX-oriented status and control 
utilities (cpnet). 

MONITOR is a customized multi-tasking monitor which 
performs task creation, task destruction and microprocessor 
dispatch. MONITOR also has memory management sub- 
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modules MEMGET and MEMFREErRESIDENT is ablocki 



of routinesth'at provides generic services such as NVRAM 
Creac[ and jyrite, FLASH code, ROM blsTdlJebuggefrhard- 
ware timer tick and other basic features. POST is a power-on 
self-test module that checks the integrity of NEB hardware 
and software at power-up. 

Flash EPROM 174 also"stores~a-Nelwork Identification- 
File ("NIF") block which stores board-mvarianynformationS 
such as the Media Access C ontrol ("MAC*) address, which 
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^is'0niquejg^r„every_netwwirboard7hardware configuration, for execution from DRAM. By virtue of^is_arrangement, it 

board~rev£ion number and thelikeras well as changeable is~possible^c^le~ct"t^ are .retrieved^ 

information such as software version number. The informa- (gomjiash EPROM 1 74 for execution out of DRAM 175 so 

tion in the NIF block is used to ensure that flash EPROM 174 as to permit flexible configuration of NEB 10L 

is not reprogrammed with an incompatible image. The NIF 5 For example, because .many~communication protocol] 

block is discussed in greater detail below in connection with ^typeTmay ^be~bToadcast"on"LAN 100, NEB 101 includes; in 

FIG. 13. flaslTEPROM~174,~software modules for supporting mul- 

All communication between NEB 101 and printer inter- tiple protocols. NEB 101 monitors all network traffic on the 

face card 150 is executed via 32 KB shared SRAM 200. heterogeneous network to determine the protocol type or 

Arbiter control logic 400, preferably a single 100-pin ASIC, 10 types in use, and loads the protocol stack or stacks which 

arbitrates between the two byte wide memory accesses of correspond to the protocols it detects into DRAM 175. 

printer interface microprocessor 151 and the single byte ^Reprogrammmg"flash"EPROM~174-with ^a^e^lmage 1 

wide memory accesses of NEB microprocessor 173, each of which may include a new protocol stack, is alsb^erformed 

which is completely independent of the other. via DRAM 175. When a new image and a command to 

Generally speaking, the 8-bit data bus of microprocessor 15 reprogram is received, such as a command received over the 

173 on board NEB 101 communicates with bus control logic network or serial port connector 600, the software repro- 

410, while the 32-bit data bus of microprocessor 151 on gramming module is loaded from EPROM 174 to DRAM 

board printer interface card 150 communicates with bus 175. Microprocessor 173, executing this module from 

control logic 420. Memory accesses from each bus are DRAM 175, confirms that the new firmware image is 

routed to shared memory arbiter 430, which determines 20 compatible with the configuration of NEB 101, and repro- 

which bus has priority (in accordance with an arbitration grams EPROM 174 if compatibility is confirmed, as 

technique discussed below) and permits the bus with priority described in more detail below. 

to access SRAM 200 via SRAM interface 440. Interrupt Microprocessor 173, executing a loaded protocol stack 

control register 450 is also accessed through shared memory out of DRAM 175, can send and receive network commu- 

arbiter 430, to allow one microprocessor to interrupt the 25 nications to and from other LAN members using that 

other. protocol. Print job data are received by network controller 
^[NEB'Fun^tiojiality] 510 and routed to microprocessor 173 through NEB control 

Broadly speaking, NEB 101 is an interactive network logic 520. Microprocessor 173 writes the print job data to 

circuit board which couples printer 102 to LAN 100, making shared memory SRAM 200, from which printer micropro- 

printer 102 a responsive and interactive network member. 30 cessor 151 reads the data and operates print engine 160 in 

NEB 101 receives print job information and status requests accordance therewith. In addition, each of microprocessors 

from LAN 100, transmits the print data and status com- 173 and 151 can write message data to the other micropro- 

mands to printer 102 for execution, receives status informa- cessor in another portion of the shared memory, 

tion from printer 102, and transmits status information back Access to the shared SRAM 200, as discussed above, is 

to LAN 100. 35 arbited by arbiter control logic 400 according to an arbitra- 

Thus, NEB 101 can not only perform RPRINTER remote tion priority technique. Arbiter control logic 400 interleaves 
printer services and PSERVER print server functionalities, concurrent accesses of the two microprocessors with one 
but can also offer to network members a wide variety of another by allowing the microprocessors access to the 
status and control features. Through NEB 101, network shared SRAM on a first-come first -serve basis, and present- 
members can access verbose amounts of status information 40 ing a wait state to the lower priority processor while the 
stored in the NEB, such as the number of print jobs, the higher priority processor takes its turn. In the case of an 
number of pages per job, the number of pages per minute, exact tie, microprocessor 173 on NEB 101 is arbitrarily 
the time per job, the number of total pages per day, and the given priority. 

number of jobs per day. In addition, a great deal of control A large portion of shared SRAM 200 is configured as a 

information may be provided from the network to printer 45 ring buffer, into which NEB microprocessor 173 writes print 

102, such as, for example, exercising the printer's front data and out of which printer interface microprocessor 151 

panel functions from a networked PC. reads it.^ As eac h processor writes or reads blocks of data, it^ 

All network traffic enters and leaves NEB 101 through ^updates respectiveTy a~"put" pointer or a "get" pointer, stored_3 

either BNC connector 302, which interfaces with network ^elsewhere in SRAM 200rto"indicate the next location that 

controller 510 through transceiver 171, or RJ-45 connector 50 me^roc^sor^should-access. 

301, which interfaces directly with network controller 510. By virtue of this arrangement, the writing processor can 

To eliminate the necessity for a user physically to position determine if there is available space in the memory in which 

a switch, NEB 101 includes hardware and software which it may write, and the reading processor can determine 

automatically detects which of the two connectorsjs coupled whether there is remaining data to be read, by comparing the 
to the network.rNetwork cc^municalibns^are transferred^ put and get pointers with one another. To reduce the amount 
between the selected connector and tj^rest^or^jboard,^^ of contention for shared memory between the two 

CwitFnetwork controller 510 along with NEB~control logic processors, NEB ^microprocessor 173 "stops writing To]^ 
520 controlling the flow of data between the network traffic memory "(and accordingly~stops reading ancTupdating"the^ 
on the selected connector and microprocessor's 173 data pointers) arpredeteTmine^inte^als, v aUowing printer inter- 
bus. 60 face microproctss^l51^ole^cess~to the memory until it 

All software modules executed by microprocessor 173 are catches up, as described in more detail below, 

stored in flash EPROM 174. Some low-level modules which Serial port connector 600 is provided to allow NEB 101 

are always needed, such as timer tick and NVRAM read, to be debugged from an external computer. Serial port 

could be executed directly out of EPROM 174, but for the connector 600 is coupled to NEB control logic 520, which 

1 most part microprocessor 173 does not execute software 65 accepts serial data from receive data pin 601 of serial port 

modules directly from flash EPROM 174, but rather selec- connector 600 and communicates the serial data bit-by-bit to 

/ tively loads those modules that are needed into DRAM 175 microprocessor 173. Microprocessor 173 configures NEB 
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control logic 520 so that a start bit in the serial data activates 
the non-maskable interrupt of the microprocessor. Micro- 
processor 173 then assembles the data bits of the serial data 
into 8 -bit words. In addition, NEB control logic 520 moni- 
tors the data bus of microprocessor 173, and passes a serial 5 
stream of the data presented thereon to transmit data pin 602 
of serial port connector 600, all as described in more detail 

below. 

{Automatic" Detection OT Network Hajrdware^ Connection]^ 
^NctwbTk"inteTfacecards generally provide severalHiffer- 10 
ent types of physical connections for connecting network 
cables to a LAN. NEB 101, for example, provides a BNC 
connector 302, to which a 10Base-2 coaxial cable may 
couple, and an RJ-45 connector 301 to which lOBase-T 
unshielded twisted pair (UTP) wire may couple. Other 15 
physical connections, such as an IBM data connector for a 
shielded twisted pair (STP) wire or an ST fiber optic 
connector for a fiber optic cable, are also possible. 

Typically, when a network interface card is connected to 
a LAN through one of its several connectors, a user who 20 
establishes or changes the connection with the LAN must 
not only insert the LAN cable in the proper connector, but 
must also physically change the position of a hard switch, or 
"jumpers", so that data is routed to and from the proper 
connector. 25 

Due to human error, however, it is possible for the user to 
forget to change the jumpers, or to put the jumpers in an 
improper state with respect to the connection that has been 
established. In such a situation, of course, the card could not 
talk to the network at all. Isolating and correcting the 30 
problem results in an unacceptable waste of time, manpower 
and computer resources. A network interface card which 
automatically senses which connector has been connected to 
the LAN, and then routes data to and from that connector, 
would greatly streamline the process for establishing and/or 35 
changing connections. 

The present invention provides for such automatic detec- 
tion of the hardware connection by testing, in turn, each of 
the connectors for an indication of network connectivity, and 
thereafter selecting one of the connectors so that network 40 
communications can be~trahsfelTed~betweeh~"the selected j 
connector~and'the _ oirboard processor/ Briefly!" a network 
controller includesTfirst defector which detects whether the 
first connector is electrically connected to the network, and 
a first register, which the processor can read, which stores a 45 
"jabber'' bit which indicates whether the second connector is 
improperly terminated. A second register, which the proces- 
sor can also read, stores a "good-link" bit which indicates 
that the first detector has detected that the first connector is 
electrically connected to the network, and a control register, 50 
to which the processor can write, stores a select bit. The 
control register outputs the selection signal in accordance 
with the select bit stored therein. 

The microprocessor executes a software-controlled selec- 
tion process by (1) writing a select bit to the control register 55 
so as to cause output of a selection signal which selects the 
first connector (here, RJ-45 301), (2) reading the good-link 
bit from the second register, (3) maintaining the state of the 
selection bit when the good-link bit indicates electrical 
connection to the network, (4) writing a select bit to the 60 
control register so as to cause output of a selection signal 
which selects the second connector (here, UTP 302) when 
the good-link bit does not indicate electrical connection to 
the network, (5) reading the jabber bit from the first register, 
(6) maintaining the state of the select bit when the jabber bit 65 
does not indicate improper electrical termination of the 
second connector, and (7) repeating the selection process 



when the jabber bit indicates improper electrical termination 
of the second connector. This sequence allows the selection 
process to take place long after power-on of the board. Once 
a selection is made, it is maintained for the entire power-on 
cycle of the board. 

More particularly, and referring to FIG. 8, BNC connector 
302 (through transceiver 171) and RJ-45 connector 301 are 
each coupled to selector 511 in network controller 510. 
Network traffic flows to and from microprocessor 173 
through bus 181 via either BNC connector 302 or RJ-45 
connector 301, depending on the state of selector 511. The 
position of selector 511 is determined by the output of 
control register 521. 

When RJ-45 connector 301 is coupled to a LAN, an 
electric current will be present at the connector. Accordingly, 
network controller 510 includes a good-link detector 512 
which monitors RJ-45 connector 301 to determine whether 
RJ-45 connector 301 is electrically connected to LAN 100. 
In the 83902 network controller, good-link detector 512 is 
configured as an open drain N-channel device. When an 
electrical current is detected at RJ-45 connector 301, the 
output of good-link detector 512 will be low and status LED 
305 will be lit, indicating an electrical connection. If there is 
no current at RJ-45 connector 301, on the other hand, the 
output of good-link detector will go high, turning off status 
LED 305. The output of the good -link bit is also fed to 
good-link register 522 in NEB control logic 520, which 
allows microprocessor 173 to read the state of the good-link 
signal. 

A BNC connector, such as BNC connector 302, will 
"jabber" unless the connector is properly terminated, such 
as, for example, when it is coupled to a LAN with a T-type 
coaxial adapter. Network controller 510 includes jabber 
detector circuit 513, which detects whether there is jabbering 
at BNC connector 302 in a manner well known in the art, 
and writes the result of its detection into jabber register 514. 
Thus, jabber register 514 contains a bit which indicates 
whether BNC connector 302 is properly terminated. The 
jabber bit can then be read by software. 

Microprocessor 173 controls the state of selector 511 by 
executing a software module stored in flash EPROM 174 in 
a manner that will now be described with reference to the 
flowchart of FIG. 9. After NEB 101 is powered-up (step 
S900), microprocessor 173 sets selector 511 to the RJ-45 
position by writing a zero to control register 521 via bus 181 
(step S901). The program reads the state of good-link 
register 522 (step S902), and, if the bit stored in good-fink 
register 522 is low (indicating an electrical current), the 
program determines that RJ-45 connector 301 is coupled to 
LAN 100, and exits, leaving selector 511 in the RJ-45 
position (S903-S904). 

Because there is an inherent delay in the switching of the 
N-channel device which comprises good-link detector 512, 
it is necessary to give good-link detector 512 ample time to 
detect an electrical connection. Accordingly, if the bit stored 
in good-link register 522 is high (indicating no electrical 
connection), the program will re-read good -link register 522 
repeatedly, exiting and leaving selector 511 in the RJ-45 
position if the bit is low for any of the reads (steps S905- 
S906-S902). If the bit stored in good-link register 522 is 
high after five hundred reads, however, the program sets 
selector 511 to the BNC position by writing a one to control 
register 521 (step S907). 

The program then reads jabber register 514 (step S908). 
If the state of jabber register 514 is low (indicating that BNC 
connector 302 is properly terminated and a BNC connection 
is present), the program exits, leaving selector 511 in the 
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BNC position (steps S909-S910). If the state of the jabber 
bit is high (indicating that BNC connector 302 is improperly 
terminated and thus not connected to LAN 100), the pro- 
gram returns to S901, resetting selector 511 to the RJ-45 
position. The program then re-executes itself cyclically until 
either an RJ-45 or a BNC connection has been established. 

Thus, NEB 101 will continue to toggle between BNC 
connector 302 and RJ-45 connector 301, checking after each 
toggle whether that particular connector is connected to 
LAN 100. By virtue of this arrangement, NEB 101 is able to 
determine, at power- up (and until a connection is made), 
whether its BNC connector 302 or its RJ-45 connector 301 
has been connected to the network, without requiring an 
operator to physically change a switch. Accordingly, the 
possibility that NEB 101 will attempt to communicate with 
LAN 100 through a connector that is not coupled to LAN 
100 is eliminated. 

In the present embodiment, the selected hardware con- 
nection is maintained during the current power-on cycle. It 
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By registering a frame type with LSL, a software module 
above LSL instructs LSL to provide the module with all 
frame packets that match the registered frame type. 

In step S1003, microprocessor 173 loads PRETASK on 
top of LSL. As mentioned above, PRETASK is responsible 
for identifying what frame types are associated with the 
various protocols in which NEB 101 is adapted to commu- 
nicate. In step S1004, PRETASK registers to receive from 
LSL all frame types that are supported by MLID. Thus, in 
the Ethernet environment of the present embodiment, PRE- 
TASK registers 802.2, 802.3, Ethernet__II and Ethernets 
Snap with LSL, thereby instructing LSL to provide PRE- 
TASK with all frame packets which match any of the 
registered frame types. 

Flow then advances to step S1005 in which MLID and 
LSL monitor the network for any traffic. Specifically, in step 
S1005, the network is monitored for broadcast traffic mean- 
ing that the destination of the traffic is unspecified (i.e., "to 
anyone"), ordinarily; broadcast traffic is identified by a 



is possible to implement software which, after a selection is 20 global specification for the destination MAC address, for 



made, senses when the hardware connection is no longer 
valid, and then repeats the selection process, thereby per- 
mitting connectors to be changed during the current power- 
on cycle. This allows for dynamic switching form one 
cormecjio^Jo_anpther.__ _ 
[Network Protocol Sensor] \ 

Toensure~proper operation^ in a multi-proto col s ystem^) 
and to guard against making impropef^ssumptions concern- 
ing the protocol and frame type being used on a network, 
NEB 101 utilizes autoprotocol detection to determine frame 
types used by network traffic, and to correlate those frame 
types with a particular one of several different protocols 
available to NEB 101. Specifically, through use of the 
PRETASK module stored in flash EPROM 174, NEB micro- 
processor 173 is able to determine which frame type is being 
used for network traffic, to correlate that frame type to one 
of several different protocols, and to load a protocol stack 
(such as IPX/SPX or TCP/IP) from flash EPROM 174 so as 
to carry out network communications using that protocol 
and the detected frame type. 

FIGS. 10 and U(fl) through 11(d) are used for describing 
this process. FIG. 10 is a flow diagram showing process 
steps executed by NEB microprocessor 173 in accordance 
with the PRETASK software module loaded in flash 
EPROM 174. PRETASK is similar to, though different from, 
the PRESCAN software module which is described in 
co-pending application Ser. No. 07/978,409, "Method And 
Apparatus For Adaptively Determining The Format Of Data 
Packets Carried On A Local Area Network", the contents of 
which are incorporated herein by reference. 

In step S1001, microprocessor 173 loads MLID (multi- 
link interface driver) from flash EPROM 174 into DRAM 
175 and begins execution of MLID. As described above, 
MLID is the lowest level of software that communicates to 
the network. MLID thus acts as the direct software interface 
to the network frame packets which are carried on the 
network wire. 

In step SI 002, microprocessor 173 loads LSL (link sup- 
port layer) on top of MLID and begins executing LSL. LSL 
acts as a multiplexer between the low level MLID and 
various protocol stacks which may be loaded above it. In 
particular, LSL accepts registrations of any of the various 
frame types with which frame packets may be carried on the 
network. Thus, for example, in an Ethernet environment, 
LSL will accept registrations of 802.2, 802.3, Ethernet_ll 
and Ethemet_Snap, and in a Token-ring environment LSL 
will accept registrations for 802.5 and Token_Ring_Snap. 
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example 12 hexadecimal F's in sequence. Until LAN broad- 
cast traffic is detected, PRETASK does nothing. 

At this point in PRETASK's execution, the relationship of 
the various software modules is as depicted in FIG- jl(fl). As 
seen there, it isjKKstt^foT^ 

as devices 182, 183, 184Tniri85, each of which runs a 
different protocol using a different frame type, all to be 
connected to a single LAN 100. In FIG. 11(a), device 182 is 
a Novell device running an IPX/SPX protocol using an 
802.2 frame type; device 183 is a UNIX network device 
running a TCP/IP protocol using an Ethernet_II frame type; 
device 184 is a Macintosh device running an EtherTalk 
protocol using an Ethernet_Snap frame type; and network 
device 185 is an unidentified frame and protocol device 
using an 802.3 frame type. Of course, the combinations 
shown in FIG. 11(a) are illustrative only, and it is possible, 
for example, for a Novell IPX/SPX to use an 802.3 frame 
type or any of the other frame types. The only requirement 
is that each protocol is associated with one and only one 
frame type. 

NEB 101 is also connected to LAN 100 and includes LSL 
187 loaded on top of MLID 186. PRETASK 188 is shown 
as having registered each of the different frame types which 
may be broadcast on LAN 100. Thus, as shown in FIG. 
11(a), PRETASK 188 has registered 802.2 at 189, Ethernet_ 
II at 190, Ethernet_Snap at 191, and 802.3 at 192. 

When LAN broadcast traffic is detected, flow advances to 
step S1006 in which LSL provides the frame packet to 
PRETASK. In step S1007, PRETASK decodes the frame's 
protocol header so as to identify the protocol in use by that 
frame packet. The offset to this header varies depending on 
the frame type the protocol is using. The following table 
includes some examples of hexadecimal values and the 
protocol headers that identify the different protocols: 



55 



60 



Hexadecimal \fclue 


Protocol Type 


0800 


IP 


0806 


ARP 


809B 


EtherTalk 


8137 


[PX/SPX 



FIG. 11(6) illustrates this sequence. As seen in FIG. 11(6), 
65 network device 182 has issued a broadcast frame packet 
using an 802.2 frame type. Since PRETASK has registered, 
at 189 as shown in FIG. 11(a), 802.2 with LSL, LSL 
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provides the frame packet to PRETASK. PRETASK decodes 
the frame's protocol header using the above table so as to 
determine the protocol in use by that frame type. 

Reverting to FIG. 10, in step S1008, PRETASK 
de-registers the frame type just received from LSL. Thus, as 
shown at 189a in FIG. 11(6), PRETASK has de-registered 
802.2. 

While step S1008 shows de -registration in all cases, there 
are some cases in which it is more preferable not to 
de-register. Particularly, each different protocol has associ- 
ated with it a list of allowable frame types. Examples of 
allowable frame types for IPX/SPX and for TCP/IT are as 
follows: 



IPX/SPX 


TCP/IP 


Ethernet_U 


Ethernet_II 


Ethernet_Snap 


Ethcrnct_Snap 


802.2 




802.3 





As is evident from the above list, it is possible for two of 
the frame types (Ethernet_JI and Ethernet_Snap) to be used 
by different protocols. It should also be noted that it is 
permissible for the same frame type to be used by different 
protocols on the same LAN. Thus, in a preferred mode, 
de-registration in step S1008 is not performed when the 
frame type received by PRETASK in step S1006 can be used 
by a protocol that has not already registered with LSL (see 
step SI 010, below). This preferred mode allows detection 
and operation of all protocols permissible on the LAN, since 
even later-received frame types for a protocol different from 
those already registered can be properly detected and pro- 
cessed by PRETASK so as to load that different protocol. 

In step S1009, PRETASK loads the protocol stack that 
corresponds to the protocol decoded in step S1007. In the 
example being used in FIG. 11(6), since an IPX/SPX pro- 
tocol is decoded, PRETASK loads the IPX/SPX protocol 
stack from flash EPROM 174. Before loading, the protocol 
stack is initialized with the frame type, here 802.2, just 
received from LSL. 

In step S1010, the newly-loaded protocol stack registers 
itself with LSL, as shown, for example, in FIG. 11(c). As 
seen there, the IPX/SPX protocol stack registers 802.2 with 
LSL. By registering, and as described above, IPX/SPX 
informs LSL to provide all frame packets matching the 
registered frame type (here, 802.2) to the newly-loaded 
protocol stack. 

PRETASK then returns to step S1005 so as to continue 
monitoring the network for broadcast traffic. If LSL encoun- 
ters frame packets which match the remaining frame types 
registered by PRETASK, LSL provides those frame types to 
PRETASK for processing in accordance with FIG. 10. Thus, 
as additional frame types are encountered, such as a frame 
type associated with a TCP/IP protocol, those frames are 
processed by PRETASK so as to load the appropriate 
protocol stack from flash EPROM 174. 

Meanwhile, as shown in FIG. ll(rf), since a protocol stack 
has been loaded, it now begins to operate on the network. 
Specifically, whereas PRETASK was completely passive 
and did not broadcast any network communications, IPX/ 
SPX broadcasts its associated SAP requests. Other protocol 
tasks loaded by PRETASK would broadcast their associated 
requests. For example, if a TCP/IP protocol stack were 
loaded then that protocol slack would broadcast RARPs so 
as to obtain its address from the nearest network server. 
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'^[Smart-Flash]!^ 

As local area networks grow more complex, it becomes 
necessary to upgrade network interface cards, such as NEB 
101, with the most current technologies available. Thus, 

5 (while-NEB"101~is-shipped with operational softwarerthat" 
r software can be reprogrammed subsequently over LAN 100^ 
For example, from the network administrator's PC 103,-the- 
network administrator can remotely alter the ROM firmware' 
image ~in~flasb~ EPROM 174 by downlo adin g new data^ 

10 which may contain for example^paTch codes, manufacturing 
test routines, entire firmware updates, and different language 
versions. 

A typical PC may be connected to more than one LAN. 
For example, as shown in FIG. 12, PC 103 is connected to 

is LAN 100, which is an Ethernet LAN, and to LAN 193, 
which is a Token-ring LAN, and may in fact mnction asjhe 
network administrator's PC for both networks. ;Eachj)fjhe 
(LANs mayTri turn be connected t o several printers^ each^of^ 
(which houses an ind|vidud NEB>, Other reprogrammable 

20 ^devices might also be connectedj o one~ or both~bf ttieljANsT^ 
Thus71h^rc~areniiultiple~NEBs, or other devices, which the~ 
network administrator can potentially reprogram. 

To reprogram a particular NEB, the network administrator 
from PC 103 activates a program that scans the network 

25 bindery to identify suitable flash targets from all network 
devices connected to the network. Suitable flash targets 
include all NEB-like devices which have flash capabilities 
and include Ethernet devices and Token-ring devices. [They 
network administrator" selects one of nhe devices-for repro- 

30 gramming and establishes network communication with thai) 
(^device. The flash EPROM on board then reprogramsjtself 
(with the new image. ; ~~ " 

"Because thVnetwork administrator may be administrating 
two or more networks, each of which Jias several repro- 

35 grammable boards connected to it,(tfiejiHmmj^ 

^ertairrtharthe~proper~image is senttottie targetedNEB) 
Thlis7inlhTcase~whefe the network administrator wishes to 
reprogram flash EPROM 174 on NEB 101 (where the NEB 
is connected to an Ethernet LAN), he must be certain that the 

40 image he sends is an Ethernet image, and that it is compat- 
ible with other aspects of NEB 101. 

The results of downloading an incompatible image can be 
devastating. For example, if the network administrator erro- 
neously downloads a Token-ring image to NEB 101, and 

45 NEB 101 subsequently reprograms its flash EPROM 174 
with that image, then NEB 101 will no longer be able to 
communicate on Ethernet LAN 100 at all. This means that 
NEB 101 could not even be reprogrammed over LAN 100; 
it is, quite literally, a "dead" board as far as the Ethernet 

50 LAN is concerned. Other incompatibilities, such as, for 
example, incompatibilities in the host interface configura- 
tion (the type of interface between the NEB and the periph- 
eral in which it is housed), product configuration (the NEB's 
board type), processor configuration (the type and speed of 

55 the processor on board), and memory configuration (the size 
and erasability of the various on board memories), can result 
in problems as well. Thus, where there are prior generations 
of a product, flashing software which works only with newer 
generations will also result in a "dead" board. 

60 To prevent such disastrous results in the casejwhere an 
incompatible image is downloaded, NEB 101 includesTa 
.softwarecode which~ensures that "the~d6wnloaded image is^> 
/compatible before actual reprogramming occurs^More^ 
•particularly, flash EPROM~174~in NEB 101 stores a y current 

65 program image which includes a network information file 
(N1F) block which contains configuration information for 
NEB 101, and a software module for reprogramming flash 
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EPROM 174. Microprocessor 173 sends and receives net-^ 
work communications, and when jrnew program image is^ 
received over ttie jne tw o rk, microprocessor 173 downloads 
the~new"image into DRAM 175, confirms that the new 
program image is compatible with the configuration infor- 
mation in the NIF block, and reprograms flash EPROM 174 
only in the case where compatibility is confirmed. 

In greater detail, the NIF block contains permanent, 
adapter specific configuration information, and is unique for 
each individual NEB. In a preferred embodiment, the NIF 
block occupies 32 bytes of memory space in flash EPROM 
413, and is divided into 4 banks of 8 bytes each. As shown 
in FIG. 13, the NIF block includes a MAC address infor- 
mation bank, a board version and identification information 
bank, a component identification information bank and a 
general information bank. 

The MAC address information bank, as the name implies, 
stores the board's unique MAC address. The board verifi- 
cation and identification information bank is subdivided into 
four smaller banks. Because network interface cards other 
than the NEB may be coupled to the LAN as well, a product 
category bank identifies the type of product coupled to the 
LAN and a board revision bank identifies the product's 
revision number. 

The network physical medium bank is further subdivided 
into a physical network bank, which identifies the physical 
medium on which the board is used (such as, for example, 
Ethernet, Token -ring or FDDI) while the supported connec- 
tors block identifies the types of physical connectors the 
board supports (such as, for example, lObaseT, 10base2 and 
10base5 in the case of an Ethernet network, and UTP and 
STP in the case of a Token-ring network). In the host 
interface method bank, the type of interface to the peripheral 
that houses the board (such as printer 102 in th^caseof NEB 
101) is identified. Examples of suc^interTacejypes include 
shared"RAM,7small computer system interface (SCSI), stan- 
dard parallel interface, RS-232C serial interface and Cen- 
tronics parallel interface. 

The component identification information bank is also 
subdivided into several smaller banks. These banks identify 
the sizes and granularities of the ROM, DRAM and 
NVRAM on the board, as well as the erasabilty of the ROM. 
In addition, the network controller (DP83902 chip in the 
case of Ethernet and TI380C25 in the case of Token-ring) 
and host controller (arbited shared RAM, NCR53C90A 
SCSI controller or NCR53C80 SCSI controller) are identi- 
fied. In the CPU identification bank, the type of processor 
and the clock speed are stored. Finally, the general infor- 
mation bank can store other data identifying additional 
configuration attributes of the board such as hardware revi- 
sion level. 

Referring to FIG. 14, a reprogramming of flash EPROM 
174 of NEB 101 begins when the CPFLASH program on the 
network administrator's PC scans the bindery (step S1401) 
and presents a list of potential flash targets to the adminis- 
trator. The administrator selects a target (step S1402) and 
CPFLASH establishes communication with the target and 
downloads the new firmware image over LAN 100 where it 
is stored in the NEB's DRAM 175 (step S1403). 

Once the new image is downloaded into DRAM 175, 
L ) NEB microprocessor 173 deactivates the protocol stack that 
it is executing, since it is, at least potentially, about to be 
programmed, and cannot engage in network communica- 
tions during that time (step SI 404). Microprocessor 173 
next copies the current NIF block from flash EPROM 174 to 
DRAM 175 (step 1405) and begins executing the software 
reprogramming module. 
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The software reprogramming module then performs 
image compatibility checks, referencing the information 
stored in the current image NIF block (which has been 
copied to DRAM 175), and comparing that information with 

5 the information stored in the new firmware image NIF block, 
to ensure that the new image is compatible (step S1406). 
Because the NIF block contains a great deal of information 
about NEB 101, a variety of checks are possible to deter- 
mine such compatibility. 

ao A first compatibility check includes a network media 
configuration check to determine if the new image is of the 
correct network medium type (e.g., Ethernet or Token-ring) 
by referencing the data stored in the physical network bank 
of the NIF block. Similarly, a second compatibility check 

15 includes a host interface configuration check to determine if 
the new image is an image for interfacing with the proper 
host (e.g., shared RAM or SCSI) by comparing the data 
stored in the host interface method and host interface 
controller banks of the NIF block with the new image. 

20 A third compatibility check includes a product configu- 
ration check that is performed by referencing the product 
category and board revision banks of the NIF block and 
comparing that data with the new image to determine 
whether the new image is for the type of board on which the 

25 EPROM is housed. Also, a processor configuration check 
can be performed by referencing the CPU bank of the NIF 
block to determine whether the new image is compatible 
with the on board microprocessor. In addition, a memory 
configuration check can be performed by comparing the data 

30 stored in the ROM, DRAM and/or NVRAM banks of the 
NIF blocks with the new image to determine whether the 
new image is compatible with the board's memory. Other 
compatibility checks, using other information stored in the 
NIF block, are also possible. 

'35 If it is determined that the new image is incompatible, the 
current protocol stack is reactivated (steps S1407-S1408) 
and an error is reported to the network administrator's PC 
103 over LAN 100, advising that an attempt has been made 
to reprogram NEB 101 with an incompatible image (step 

40 S1409). 

On the other hand, if the new image is compatible, then 
board -invariant portions of the NIF block of the new-image^s 
are-replaced with the corresponding portions of NIF block of 
'the current image,> in order to preserve-any bo ard specific 

45 information (such^as the MAC address and board revision 
number) contained therein (steps S1407-S1410). The pro- 
gram then erases the current image from flash EPROM 174, 
and reprograms flash EPROM 174 with the new image 
stored in DRAM 175, which now includes the original NIF 

50 block. 

By virtue of this arrangement, microprocessor 173 will 
never reprogram flash EPROM 174 with an incompatible 
image, even in the case where an incompatible image was 
erroneously downloaded over LAN 100. Rather, in the case 
55 where a network administrator does attempt to reprogram 
NEB 101 with an incompatible image, NEB 101 will send 
a message back to the network administrator, advising him 
of the incompatibility. Accordingly, a fail-safe measure 
against such human errors is provided in an inexpensive, 
60 efficient^way. 
^[Arbitration Device]^ 

FIGS. 15 through 17 are views for explaining arbitration 
of shared SRAM 200 in response to access requests from 
printer interface card 150 or from on-board NEB micropro- 
65 cessor 173. 

FIG. 15 shows printer address/data bus (A/D bus) 701, 
print address latch enable (ALE) signal 702, printer data 
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enable (DEN) signal 704, printer clock line 705 and printer 
ready signal 706. These signals are aU received via printer 
interface connector 170 from printer interface card 150. 
Specifically, for example, A/D bus 701 is the A/D bus for 
printer microprocessor 151 mounted on printer interface 
card 150. Printer ALE signal 702 is a signal indicating when 
valid address information is carried on A/D bus 701, and 
printer DEN signal 704 is a signal indicating when valid data 
information is carried on A/D bus 701. Printer clock 705 is 
the main clock signal for printer microprocessor 151, and 
printer ready signal 706 is a signal which, when false, 
indicates to microprocessor 151 that a memory access is not 
complete and that microprocessor 151 should insert wait 
states until memory access is complete. 

Also shown in FIG. 15 is NEB address/data bus (A/D bus) 
711, NEB ALE 712, read and write signals (WR and RD) 
714, NEB clock 715 and NEB ready signal 716. NEB A/D 
bus 711 is the main address bus for microprocessor 173, and 
carries address and data information for all components 
mounted on NEB 101. NEB ALE signal 712 is a signal 
indicating when the valid address information is available on 
A/D bus 711, read and write signals 714 are signals indi- 
cating when valid data information is available on A/D bus 
711 and, in addition, whether to read or to write that data, 
NEB clock 715 is a main clock signal supplied by crystal 
oscillator 172, and NEB ready signal 716 is a signal which, 
when false, indicates to NEB microprocessor 173 that a 
memory access is not yet available and that microprocessor 
173 should insert wait states until memory access is avail- 
able. 

Printer microprocessor 151 and NEB microprocessor 173 
communicate, as mentioned above, through shared SRAM 
200. Access requests for shared SRAM 200 are issued by 
microprocessor 151 and microprocessor 173 on A/D buses 
701 and 711, respectively, and are arbitrated by arbiter 
control logic 400, as described above. More particularly, and 
as described above with respect to FIG. 6, arbiter control 
logic 400 includes bus control logic 410 for controlling the 
bus accesses on NEB A/D bus 711, bus control logic 420 for 
controlling bus traffic on printer A/D bus 701, shared 
memory arbiter 430 for arbitrating between access requests 
on A/D bus 701 and A/D bus 711, SRAM interface 440 for 
interfacing printer A/D bus 701 and NEB A/D bus 711, 
respectively, to address and data buses for SRAM 200. Each 
of those sections is described in more detail below. 

Bus control logic 410 includes latch 717 which latches 
address information on NEB A/D bus 711 in response to 
NEB ALE signal 712 so as to provide latched address 
information 719. Decoder 720 decodes latched address 
information when read or write signal 714 is active so as to 
provide a NEB request signal (NREQ signal) 721 in the 
event that address information on NEB A/D bus 711 corre- 
sponds to address space of shared SRAM 200. 

Likewise, bus control logic 420 includes latch 722 which 
latches address information on printer A/D bus 701 when 
printer ALE signal 702 is high so as to provide latched 
address information 724. A decoder 725 is responsive to 
latched address information and outputs a printer request 
signal (PREQ) 726 when printer DEN signal 704 is active in 
the event that the latched address information corresponds to 
address space of shared SRAM 200. 

Shared memory arbiter 430 includes synchronization cir- 
cuitry to synchronize the PREQ and NREQ access request 
signals to a common clock, here NEB clock 715, a delay 
circuit which inserts a fractional clock delay into one of the 
request signals, a hold off circuit which grants access to a 
first-received request signal and holds off access to later- 
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received access requests, and a re-synchronization circuit. 
Specifically, both NREQ 721 and PREQ 726 are provided to 
synchronization circuits which are both synchronized to 
NEB clock 715 so as to synchronize both access requests to 

5 a common clock. In the specific instance illustrated herein, 
PREQ, which is inherently synchronized to its own printer 
clock signal 705 is synchronized to NEB clock signal 715. 
Delay 729 is inserted into one of the access request signals, 
here into the access request signal from the printer, so as to 
produce offset request signals. The delay circuit inserts a 
fractional clock delay, such as a one-half clock delay, so as 
to ensure that even if both access requests are issued at 
exactly the same time, one access request will reach hold off 
circuit 730 before the other. 

Hold off circuit 730 outputs first and second access grant 

35 signals PACK and NACK, in correspondence to the first and 
second access request signals. Exactly one of the first and 
second access grant signals is activated in correspondence to 
which of the first and second offset request signals is 
received first. The other (or later- received) offset request 

20 signal is held off until processing of the first -received access 
request signal is complete. To indicate to the held-off micro- 
processor that access is denied, a not-ready signal is issued. 
For example, in a case where a NEB access request is 
received after a printer access request, hold off circuit 730 

25 grants access to the printer and holds off access by the NEB. 
In that case, NEB ready signal 716 is de-asserted indicating 
to microprocessor 173 to insert wait states until access is 
granted. Conversely, if a NEB access request is received 
before a printer access request, hold off circuit 730 grants 

30 access to the NEB and holds off access to the printer. In that 
case, hold off circuit 730 delays printer ready signal 706 to 
indicate to microprocessor 151 to insert wait states until 
access is granted. 
The PACK access grant signal for the printer is then fed 

35 to the re-synchronization circuit 731 in which the 
de-synchronized signal is re-synchronized with its own 
clock. The re-synchronized signal is designated as FPACK. 
The re-synchronized access grant signals, FPACK and 
NACK, are then fed to SRAM interface 440 which provides 

40 proper interface between the microprocessor that has been 
granted access and the shared SRAM 200. 

Shared memory arbiter 430 is preferably constructed from 
D-type flip flops and standard logic circuitry. One preferred 
construction is shown in FIG. 16. As seen there, access 

45 request signal 726 from the printer is fed to a synchronizing 
D-type flip flop 728a which is clocked by NEB clock signal 
715 and subsequently to a second D-type flip flop 7286. At 
the same time, access request signal 721 from the NEB is fed 
to the input of a D-type flip flop 121a and subsequently to 

50 a second D-type flip flop 121b, These two flip flops 727a and 
121b are provided so as to ensure suitable synchronization 
and delay of access request signal 721. Trailing-edge- 
triggered D-type flip flop 729 is provided so as to insert a t V4 
clock delay into access request signal 726 from the printer. 

55 Output of flip flop 729 is held low by reset signal 732 which 
is provided in the event that an access grant signal has 
already been provided to the NEB (i.e., the NACK signal is 
high). On the other hand, if access has not yet been granted 
to the NEB, then any access request signals from the printer 

60 are clocked through so as to form the PACK signal. The 
PACK signal is sent to re-synchronization flip flop 731 
which is clocked by printer clock 705. At the same time the 
PACK signal is provided to NAND gate 734 which operates 
in conjunction with the clocked NEB access request signal. 

65 If access has been granted to the printer, then NAND gate 
734 ensures that access is not granted to NEB, even if 
requested, until PACK goes low. 
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By virtue of the arrangement shown in FIG. 16, although 
the hold off circuit 730 outputs first and second grant signals, 
only exactly one of those first and second grant signals is 
activated at any one time. That is, if access is granted to the 
printer, then access is held off to the NEB; conversely, if 
access is granted to the NEB, access is held off to the printer. 

Returning to FIG. 15, SRAM interface 440 receives the 
re-synchronized printer access grant signal FPACK as well 
as NEB access grant signal NACK and, based on which of 
those signals is active, coordinates access between either 
printer microprocessor 151 or NEB microprocessor 173 to 
shared SRAM 200. 

More particularly, as shown in FIG. 15, the NEB access 
grant signal NACK is provided to multiplexer 735 which 
selects either latched NEB address information 719 or 
latched printer address information 724 in accordance with 
the NACK signal and provides the selected address infor- 
mation onto internal address bus 736. In the case that NACK 
is active, then multiplexer 735 provides all thirteen (13) bits 
of latched NEB address information 719 onto internal 
address bus 736. On the other hand, if NACK is not active 
(i.e., the printer has access), then multiplexer 735 provides 
twelve of the thirteen bits of latched printer address infor- 
mation 724 onto internal address bus 736. The thirteenth bit, 
here AO, is provided by generator 747, in a manner 
described below. 

Buffer 737 buffers address information from internal 
address bus 736 onto SRAM address bus 740. Buffer 737 is 
activated from the output of OR gate 739. OR gate 739 
accepts as one of its inputs the NEB access grant signal 
NACK; accordingly, as soon as NACK goes high buffer 737 
buffers the address information on internal address bus 736 
onto SRAM address bus 740. 

In accordance with whether a read or a write is requested, 
that is, in accordance with the status of the read or write 
signal 714, SRAM 200 either receives or puts data infor- 
mation onto its data bus 741. That data information is 
transferred via bi-directional buffer 742 onto internal data 
bus 744. Bi-directional buffer 742 is activated by the output 
from OR gate 745 which accepts as one of its inputs NEB 
access grant signal NACK. Accordingly, when NACK goes 
high, the output of OR gate 745 goes high which in turn 
allows transfer of data information from SRAM data bus 
741 to internal data bus 744. Data information on internal 
data bus 744 is transferred to NEB A/D bus 711 by 
bi-directional buffer 746 which is activated by the NEB 
access grant signal' NACK. Since the NEB access grant 
signal NACK derives itself ultimately from decoder 720 
which is triggered by read or write signal 714, timing of data 
information on NEB A/D bus 711 is proper inasmuch as bus 
711 no longer expects valid address data to appear on it but 
rather now expects valid data information to appear on it. 

Thus, in summary, when the NEB is granted access to 
shared SRAM 200, latched address information from latch 
717 is buffered onto SRAM address bus 740 via multiplexer 
735 and buffer 737, and data information is buffered to (or 
from) NEB A/D bus 711 from (or to) SRAM data bus 741 
via bi-directional buffers 742 and 746. When access opera- 
tions for the NEB are complete, any held off access requests 
from the printer are processed. 

In the event that printer microprocessor 151 has been 
granted access to shared SRAM 200, then even though 
printer microprocessor 151 uses the same 13-bit wide 
address that NEB microprocessor 173 uses, because micro- 
processor 151 has a data bus width which is different than 
that of SRAM 200, upper- and lower-byte buffers are 
required so as to resolve these bit-width differences. More 
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particularly, as described above, printer microprocessor 151 
is a 32-bit Intel 80960KB RISC microprocessor which, 
through convention, communicates with external devices 
through 16-bit wide shared RAM data access. Resolution of 

5 16-bit accesses to internal 32-bit format of printer micro- 
processor 151 is left to the printer microprocessor. However, 
resolution of 16 -bit data accesses from microprocessor 151 
to 8-bit wide shared SRAM 200 is left to SRAM interface 
440 and the above-mentioned upper byte and lower byte 

10 buffers. That structure is described in more detail below. 
More particularly, for address information latched in latch 
722, multiplexer 735 transfers twelve of the thirteen bits 
onto internal address bus 736. The thirteenth bit, here AO, is 
provided from generator 747. Generator 747 is activated by 

15 lower strobe output 750 and upper strobe output 752, both 
from strobe generator 751. Strobe generator 751 is arranged 
so as to provide two consecutive signals, lower strobe 750 
and upper strobe 752, in response to receipt of an FPACK 
access grant signal from shared memory arbiter 430. Lower 

20 strobe signal 750 is provided to generator 747 which, in turn, 
provides a binary zero bit for the thirteenth address bit to 
multiplexer 735. Multiplexer 735 selects these thirteen 
address bits onto internal address bus 736. The address 
information on internal address bus 736 is, as mentioned 

25 above, latched onto SRAM address bus 740 via buffer 737. 
Buffer 737 is activated by output of OR gate 739 which 
includes as its inputs upper strobe 752 and lower strobe 750. 
Thus, in response to each consecutive upper and lower 
strobe signal 750 and 752, OR gate 739 outputs a signal to 

30 buffer 737 which causes address information on internal 
address bus 736 to be transferred to SRAM address bus 740. 

Upper address strobe 752 is also provided to generator 
747 which generates a binary one bit for the thirteenth 
address bit to multiplexer 735. Multiplexer 735 selects those 

35 thirteen bits onto internal address bus 736. That modified 
address information is, in sequence with receipt of upper 
strobe 752 by OR gate 739, transferred to address bus 740 
of SRAM 200. 

Handling of data information depends on whether a read 

40 or a write is requested by printer microprocessor 151. In the 
case of a write, strobe generator 751 provides lower strobe 
signal 750 to buffer 754 which buffers the lower byte of data 
information on printer A/D bus 701 to internal data bus 744. 
That data information is buffered to SRAM data bus 741 via 

45 bidirectional buffer 742 which is activated by output of OR 
gate 745 which, in turn, accepts as one of its inputs the 
printer access grant signal FPACK. Thus, the lower byte of 
data information on printer A/D bus 701 is transferred via 
buffer 754 onto internal data bus 744 and thence to SRAM 

50 data bus 741. 

The upper byte of data information on printer A/D bus 701 
is buffered by buffer 755 which is activated by upper strobe 
signal 752 from strobe generator 751. As before, that upper 
byte of data information is transferred onto internal data bus 

55 744 and thence to SRAM data bus 741 via bi-directional 
buffer 742. 

When printer microprocessor 151 requests a read of 
SRAM data, lower strobe signal 750 and upper strobe signal 
752 are delayed by respective delays 756 and 757 and the 

60 delayed strobes control respective latches 758 and 759. 
Those latches latch respective lower and upper bytes pro- 
vided from data bus 741 of SRAM 200, assemble the upper 
and lower bytes onto printer A/D bus 701, and provide the 
assembled data information to printer microprocessor 151. 

65 Thus, in summary, when printer microprocessor 151 is 
granted access to shared SRAM 200, address information 
latched in latch 722 is provided to the address bus of SRAM 
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200, and data information written to (or read from) SRAM 
200 is resolved by lower and upper buffers 754 and 755 into 
data information for SRAM data bus 741 (or assembled 
from data information from data bus 741 by latches 758 and 
759). When access by printer microprocessor 151 is 
complete, any held off access requests from the NEB are 
then processed. 

OR gate 760 outputs a chip select signal 761 to shared 
SRAM 200. Inputs to OR gate 760 are lower address strobe 
750, upper address strobe 752 and NEB access grant signal 
NACK. Thus, in response to any of those signals, chip select 
signal 761 is issued. 

FIG. 17 is a timing diagram showing timing of signals 
provided to arbiter control logic 400. Specifically, on the 
printer side and as discussed above, arbiter control logic 400 
is provided with printer clock 705, printer ALE signal 702, 
printer A/D bus 701, printer DEN signal 704 and printer 
ready signal 706. In response to address information on 
printer A/D bus 701 which corresponds to address space in 
shared SRAM 200, which is valid and latched when printer 
ALE signal 702 goes high, and which thereafter generates a 
printer request signal 726 (FIG. 15) when printer DEN 
signal 704 goes low, hold off circuit 730 in arbiter control 
logic 400 generates a printer ready signal 706 to cause 
printer microprocessor 151 to generate wait states until 
access to SRAM 200 has been granted and valid data 
appears on printer A/D bus 701, as indicated when printer 
DEN signal 704 goes high. 

On the NEB side, in response to address information on 
NEB A/D bus 711 which corresponds to address space in 
SRAM 200, which is valid and latched when NEB ALE 
signal 712 goes low, and which thereafter generates a NEB 
request signal 721 when NEB write signal 714 (not shown) 
goes low, a NEB ready signal 716 is generated until access 
to SRAM 200 is granted and valid data appears on NEB A/D 
bus 711. 

[Reducing Bus Contention In Shared Memory] 

As discussed above, arbiter control logic 400 is integral to 
the design of NEB 101, in that it allows only one of the 
processors to access shared SRAM 200 at a given point in 
time. This prevents simultaneous access to the same memory 
cell, thereby preventing data corruption. However, the 
arbitration, by necessity, is performed on the entire memory 
array, and not on individual memory cells. Thus, one pro- 
cessor must wait while the other accesses the memory, even 
if the two referenced addresses are different with respect to 
one another. This can lead to very slow memory access 
times, particularly in the case where print data is being 
transferred from the network by NEB microprocessor 173 to 
printer interface microprocessor 151 via shared SRAM 200. 

FIG. 18 shows how available memory in SRAM 200 is 
divided in logical space. All data transferred from NEB 101 
to printer 102, including print job data, commands and status 
requests, are written by NEB microprocessor 173 into 
printer data area 201, from where the data are read by printer 
interface microprocessor 151. Conversely, all data trans- 
ferred from printer 102 to NEB 101 are written by printer 
interface microprocessor 151 into message data area 202, 
from where the data are read by NEB microprocessor 173. 

As is shown in FIG. 18, printer data area 201 is configured 
as a ring buffer, in which a linear memory array is addressed 
circularly so that addressing automatically restarts at the 
beginning when the end is reached. Such a memory structure 
requires two pointers: a "put" pointer which marks the next 
address in which data are to be written, and a "get" pointer 
marking the next address from which data are to be read. The 
values of these pointers are stored in SRAM 200 itself, in 
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status message area 203. The sending processor controls the 
value of the put pointer, advancing it as it writes new data 
into the ring buffer, while the receiving processor controls 
the value of the get pointer, advancing it as it copies data out. 

s Data are written into the ring buffer in blocks of 256 bytes, 
with the put and get pointers marking where the next block 
begins. For example, in FIG. 18, the put pointer points to 
block 2011, indicating that that block is the next available 
space in memory in which NEB microprocessor 173 is to 

10 write, while the get pointer points to block 2012, indicating 
that that block is the next space in memory from which 
printer interface microprocessor 151 is to read. Before 
writing a block of data into memory, NEB microprocessor 
173 reads the values of the put and get pointers from status 

15 message area 203, and compares them to determine whether 
there is available room in the ring. Similarly, printer inter- 
face microprocessor 151 reads the values of the put and get 
pointers from status message area 203 and compares them to 
determine whether there is data to be read. 

20 Thus, in transfeTrln^llata^from one processor to~another\ 
using a rih^rJuffe7Ttfte~T^ceivm^ 
sending processor "around the ring", reading out the data 
that has been written. Because the receiving processor is 
limited by the speed of the printer it is driving, however, the 

25 sending processor generally writes data in faster than the 
receiving processor can read it out, and it is likely that, in a 
conventional system, the put pointer will loop around the 
ring and "catch up" with the get pointer that is behind it. In 
such a case, the rsendin^pfo"ce^sor~simply"Wits uritil\ 

30 irn^m^rxspace^beaDmes^y^iUble^ in jhe_ring/DTirihg that 
waiting time, in conventional systems the sending processor 
reads and compares the put and get pointers periodically to 
determine if space has become available. Such polling by the 
sending processor slows down the receiving processor, since 

35 the sending processor must access the shared memory to 
read the values of the pointers, which prevents access by the 
printer and degrades the performance of the entire system. 

In NEB 101, bus contention is reduced by preventing the 
put pointer from being ahead of the get pointer by more^than 

40 (a _ predetermined~araount~and~then~ waiting^ until the get 
pointer catches iip^ rTheNEB does not poll shared SRAM 
200 to determine when the get pointer catches up with the 
put pointer, but rather relies on another device, here interrupt 
control register 450, to provide notification of when the get 

45 pointer catches up. Specifically, it is a feature of the printer 
interface that the print data can contain a command for the 
printer to generate an acknowledgement to the NEB via 
interrupt control register 450. The NEB inserts this com- 
mand in the last block of print data that it sends to the printer, 

so and uses the acknowledgement from interrupt control reg- 
ister 450 as a substitute for polling. Specifically, the NEB 
sends print data to the printer by (1) determining whether 
there is available space in shared RAM for the print data by 
reference to a counter of outstanding acknowledgements, (2) 

55 if there is available space, reading the get and put pointers 
and determining whether the put pointer is equal to one of 
plural partition indices which correspond to the number of 
partitions into which the ring buffer is divided, (3) writing a 
command requesting the receiving processor (the printer) to 

60 issue an acknowledgement in the case where the value of the 
put pointer is equal to one of the predetermined indices, (4) 
writing a block of print data into the shared memory at the 
location of the put pointer, and thereafter, (5) updating the 
value of the put pointer. When NEB 101 writes a command 

65 requesting the printer to issue an acknowledgement, it 
updates the number of outstanding acknowledgements that it 
expects to receive from the printer by adding one to the 
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counter of outstanding acknowledgements. When an 
acknowledgement is received from the printer, the counter 
of outstanding acknowledgements is reduced by one. The 
counter is not stored in shared SRAM 200, but rather is 
stored in DRAM 175 which is owned by NEB micropro- 
cessor 173 and for which there is no problem of bus 
contention. Accordingly, NEB 101 determines whether there 
is space available in the ring buffer by comparing the 
number of outstanding acknowledgements stored in the 
counter to the number of partitions into which the ring buffer 
is divided. If the number of outstanding acknowledgements 
is greater than or equal to the number of partitions, then the 
ring buffer is full and NEB 101 does not write any additional 
print information to the ring buffer; instead, it waits until an 
acknowledgement is received which indicates that the 
printer has cleared out one partition of the ring buffer and 
that that partition is now available for new print information. 
On the other hand, if the number of outstanding acknowl- 
edgements is less than the number of partitions, then there 
is still available space in the ring buffer. 

FIG. 19 shows the procedure by which the sending 
processor on NEB 101 (i.e., NEB microprocessor 173) 
writes data into shared SRAM 200. The process begins when 
a print job is received from the LAN (step S1902). When the 
print job is received, NEB microprocessor 173 determines 
whether there is space available in the ring buffer for print 
data. This is accomplished by counting the number of 
outstanding acknowledgements which are expected from the 
printer. More specifically, as mentioned above, it is possible 
for NEB microprocessor 173 to insert commands mixed 
with the print data which cause the printer to issue an 
acknowledgement which is conveyed from the printer to 
NEB microprocessor 173 via interrupt control register 450. 
NEB microprocessor 173 tracks the number of outstanding 
acknowledgements, that is, the number of commands issued 
for an acknowledgement minus the number of acknowledge- 
ments actually received. If the number of outstanding 
acknowledgements is less than the number of partitions into 
which the ring buffer has been divided (here, the ring buffer 
has been divided into two partitions), then space is available 
in the ring buffer for more print data; on the other hand, if 
the number of outstanding acknowledgements is equal to or 
greater than the number of partitions into which the ring 
buffer has been divided, then no more space is available and 
NEB microprocessor 173 waits until acknowledgements 
have been received. 

Thus, in step S1903, NEB microprocessor 173 determines 
whether an acknowledgement has been received from the 
printer. If an acknowledgment has been received, flow 
branches to step S1904 in which the number of outstanding 
acknowledgements is updated. In any event, flow then 
advances to step S1905 in which NEB microprocessor 173 
determines whether space is available in the ring buffer for 
the print data received in step SI 902. As mentioned above, 
NEB microprocessor 173 does not determine whether space 
is available by accessing the put and get pointers, since such 
accesses would cause needless bus contention. Instead, NEB 
microprocessor 173 determines whether there is space avail- 
able by comparing the number of outstanding acknowledge- 
ments to the number of partitions into which the ring buffer 
has been divided. If the number of outstanding acknowl- 
edgements is not less than the number of partitions, then no 
space is available in the ring buffer and flow returns to step 
SI 903 until an additional acknowledgement is received. On 
the other hand, if the number of outstanding acknowledge- 
ments is less than the number of partitions, then space is 
available in the ring buffer and flow advances to step SI 906. 
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In step SI 906, the put and get pointers are read from 
shared SRAM 200 from status message area 203. In step 
S1907, if the put pointer equals a partitioned index, that is, 
if the put pointer points to the end of a partition in the ring 

5 buffer, such as index A and index B in FIG. 18, then NEB 
microprocessor 173 inserts a command for the printer to 
issue an acknowledgement. More specifically, if the put 
pointer is equal to one of the partitioned indices, then flow 
branches to step S1908 in which the NEB microprocessor 

10 writes its next block of print data into the memory location 
indicated by the put pointer, but also includes in the block a 
command for the receiving processor (i.e., printer micro- 
processor 151) to issue an acknowledgement. NEB micro- 
processor 173 next updates the value of the put pointer (step 

is S1909), and then updates the number of outstanding 
acknowledgements (step SI 910). Flow then advances to step 
S1911 in which it is determined whether more print data 
needs to be sent to the printer. If more data needs to be sent, 
then flow returns to step SI 903 in which NEB micropro- 

20 cessor 173 determines whether space is available in the ring 
buffer by reference to the number of outstanding acknowl- 
edgements. 

On the other hand, if in step S1907 the put pointer is not 
equal to one of the partitioned indices, then flow continues 

25 at step SI 912 in which NEB microprocessor 173 simply 
writes its next block of print data into the memory location 
indicated by the put pointer, updates the value of the put 
pointer (step SI 913) and continues on to step SI 911 to 
determine whether more print data needs to be sent to the 

30 printer. 

The receiving processor issues acknowledgements when 
it reads from the shared memory the data block that includes 
that command. More particularly, and referring to FIG. 20, 
the receiving processor begins its data retrieval by reading 

35 the values of the get and put pointer from the shared memory 
(step S2001). If there is data to retrieve (step S2002), the 
receiving processor reads the block of data from the memory 
location indicated by the get pointer (steps S2002--S2004) 
and updates the value of the get pointer (step S2005). 

40 The receiving processor then executes any commands that 
were included in the data block (step S2006), such as, for 
example, a command to issue an acknowledgement. The 
receiving processor issues this acknowledgement as an 
interrupt to the sending processor, which it generates by 

45 writing a bit to interrupt control register 450 that is part of 
arbiter control logic 400. When the sending processor 
receives the interrupt, it updates its number of outstanding 
acknowledgements, as described above. 

Accordingly, when the ring buffer is partitioned into two 

50 partitions, the sending processor writes blocks to only half 
of the ring buffer at a time, checks if the receiving processor 
has finished reading the other half, and ceases to access the 
shared memory at each of the indices until the receiving 
processor catches up. In alternative embodiments, the ring 

55 can be further divided into finer granularities in those 
situations where two ring segments are insufficient. In those 
cases, as shown in FIGS. 21(a) through 21(c), for example, 
additional indices would be used. 

By virtue of this structure, the waiting of NEB micropro- 

60 cessor 173 will not hinder the reading of printer interface 
microprocessor 151, since NEB microprocessor 173 will not 
be accessing the shared SRAM 200 at all at that time. This 
not only achieves a greater data throughput, since the printer 
interface microprocessor 151 can accomplish its task more 

65 quickly, but also frees NEB. microprocessor 173 from 
having to poll the put and get pointers, allowing it to perform 
other work not involving shared SRAM 200. 
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[Serial Port] 

Serial port connector 600, as mentioned above, is pro- 
vided for serial communications with external processors, 
particularly a processor used in connection with debug 
services for NEB 101. Specifically, via serial port connector 
600, an external processor is able to retrieve debug infor- 
mation transmitted by NEB 101 when NEB 101 is set to a 
debug state. That information can include, for example, 
status of internal NEB registers, status of network broad- 
casts and traffic on network interface 301 (or 302, whichever 
is enabled), status of print information as well as print 
information being written to shared SRAM 200 and the like. 

Because serial port connector 600 is used in connection 
with debug services, it is imperative that serial communi- 
cations over that port are responded to by NEB micropro- 
cessor 173, regardless of the interruptability of NEB micro- 
processor 173. For example, when reducing bus contention 
by waiting to write new print data into SRAM 200 until 
printer 102 issues an acknowledgement, as described above, 
it is possible for the printer erroneously to fail to issue such 
an acknowledgment. In those cases, the NEB microproces- 
sor will loop continuously until an acknowledgement is 
received. Ordinarily, a processor in such a state is "locked- 
up" meaning that it does not respond to any interrupts; in this 
locked-up state it is ordinarily necessary to cycle power to 
the board. However, because this erroneous operation is 
precisely the kind of operation for which debug information 
is desired over serial port connector 600, it is imperative that 
NEB microprocessor 173 be able to respond to such serial 
communications. 

The arrangement illustrated in the accompanying figures 
describes a serial port construction in which signals on a 
receive channel are transmitted to the non-maskable inter- 
rupt (NMI) pin of NEB microprocessor 173. A non- 
maskable interrupt feature is available on most modern-day 
processors, such as the Intel 80X86 line of processors, and 
it provides a means for interrupting the processor regardless 
of its current computing state. That is, when the NMI pin is 
activated, the processor must respond to the interrupt regard- 
less of other operations that are currently underway. 

More particularly, as shown in FIG. 22, a serial port 
construction according to the invention includes NEB 
microprocessor 173 which includes a non-maskable inter- 
rupt (NMI) pin 1731 and which is connected via bus 181 to 
NEB control logic 520, as described above. NEB control 
logic 520 includes address decode logic 523 which decodes 
address signals on bus 181 and which provides access to 
internal registers in NEB control logic 520. Particularly, 
three registers are concerned here: transmit register 524, 
receive register 525, and NMI enable register 526. 

Transmit register 524 includes a transmit bit which is 
connected to transmit pin 602 of the serial port specifically, 
the transmit bit is writable by NEB microprocessor 173 via 
bus 181 and address decode logic 523, and in accordance 
with a binary 1 or 0 state of that transmit bit a corresponding 
+5 or 0 volt voltage level appears at transmit terminal 602. 

Receive register 525 includes a receive bit which is 
connected to receive pin 601 of the software serial port. 
More specifically., in accordance with a voltage level which 
appears at receive terminal 601, the receive bit is set to a 
binary 0 or 1, and the receive bit may be read by micropro- 
cessor 173 via bus 181 and address decode logic 523. 

NMI enable register 526 is a switch controllable by 
microprocessor 173 and which is connected between receive 
terminal 601 and NMI pin 1731. Under control of micro- 
processor 173 and via bus 181 and address decode logic 523, 
NMI enable register 526 is switchable between an enable 
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state in which signals appearing at receive terminal 601 are 
connected to NMI pin 1731, and a disable state in which 
signals appearing at receive terminal 601 are blocked. 
Transmit register 524, receive register 525, and NMI 

5 register 526 can physically be constructed from a single 
register, but more typically each are provided in a separately 
addressable register, as shown in FIG. 22. 

FIG. 23(a) shows serial port processing in a serial receive 
mode. The process steps illustrated in FIG. 23(a) are 

10 executed by NEB microprocessor 173 in accordance with 
software instructions stored in DRAM 175. 

In step S2301, microprocessor 173 enables NMI enable 
register 526 so as to permit transmission of signals appear- 
ing at receive terminal 601 directly to NMI pin 1731. Then 

15 in step S2302, microprocessor 173 monitors its NMI pin 
1731 for the appearance of an NMI signal. If no non- 
maskable interrupt has been received, microprocessor 173 
continues with ongoing processing (step S2303), such as 
continuing with networked printing operations between the 

20 computerized LAN 100 and the printer. 

On the other hand, when an NMI signal is received at 
NMI pin 1731, flow advances to step S2304 in which 
microprocessor 173 interrupts on-going processes. As seen 
in FIG. 23(£>), because NMI enable register has been 

25 enabled, an NMI signal will be received in correspondence 
to a start bit at receive terminal 601. FIG. 23(b) illustrates 
timing of signals in a serial receive mode. Thus, as seen in 
FIG. 23(6), when a voltage level 610 corresponding to a start 
bit appears at receive terminal 601, because of the enable 

30 state of NMI enable register 526, that start bit is transmitted 
to NMI pin 1731. At the same time, because of voltage level 
610 associated with the start bit, the receive bit in receive 
register 525 switches to a binary 1. 

Reverting to FIG. 23(a), after microprocessor 173 inter- 

35 rupts on-going processes (step S2304), the microprocessor 
begins execution of an NMI interrupt handling procedure 
which, in step S2305, disables NMI enable register 526 so 
as to block transmission of other signals from receive 
terminal 601 to NMI pin 1731. The interrupt handling 

40 procedure then waits for a serial transmission period so as to 
allow the first data bit to appear at receive terminal 601. In 
situations where serial transmission is conducted at 19,2 
KHz, the predetermined serial transmission period is 1/19.2 
KHz or 52 /<s. After the predetermined serial transmission 

45 period is over, flow advances to step S2307 in which the 
received bit in receive register 525 is read. This is shown in 
FIG. 23(b) in which, for illustrative purposes, the first data 
bit is a binary 1 corresponding to a high voltage level at 
receive terminal 601. The received bit is retrieved from 

50 receive register 525 and steps S2306 and S2307 are repeated 
(step S2308) until eight data bits have been received. Any 
stop bits (such as 611 in FIG. 23(b)) that are transmitted are 
simply ignored. 

When eight data bits have been received, flow then 

55 advances to step S2309 in which the interrupt handling 
procedure stores an 8-bit byte of data which has been 
received at the receive terminal 601. In step S2310, micro- 
processor 173 enables the NMI enable register 526 so as to 
be prepared for receipt of a next serial transmission. The 

60 serial communication cycle for receiving one byte of serial 
data is then complete. 

In step S2311, microprocessor 173 determines whether 
the 8-bit byte stored in step S2309 requests an asynchronous 
break-in to ongoing software tasks. More specifically, once 

65 the NMI interrupt handling procedure described above has 
terminated, flow ordinarily returns to ongoing processes 
such as CPSOCKET and the like, all under control of the 
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MONITOR. One benefit of an NMI-driven serial port, 
however, is the ability to break into a running program in the 
midst of a problem. For example, in situations where the 
NEB has crashed due to unexpected software problems, the 
state of the NEB is often unknown. It might be in a very tight 5 
microprocessor loop that has no debug messages being 
transmitted. Resetting the NEB, which is often the only way 
to break the microprocessor loop, will lose the current state 
and will provide no information as to the cause of the crash. 
In such a situation, the ability to break it via the NMI-driven 3Q 
serial port and examine the system is extremely valuable. 

Accordingly, step S2311 determines whether the byte 
received on the serial port connector requests asynchronous 
break-in. For example, by previously-arranged convention, 
it might be determined that transmission of an exclamation 
point ("!") signifies a request for asynchronous break- in. In 15 
those instances, microprocessor 173 continues to suspend 
ongoing processes, and enters an interactive debugger. The 
interactive debugger is a ROM-resident program that allows 
a user to view or to change memory addresses, CPU 
registers and I/O ports. Additionally, the interactive debug- 20 
ger allows two set break points in the code and has the ability 
to start execution from any such break point. This is all 
accomplished across serial port connector 600. 

Thus, asynchronous break- in permits a trouble-shooter to 
analyze the current state of NEB when a problem has been 2 s 
encountered. Since the start bit on a serial communication 
causes an NMI signal to be generated, asynchronous break- 
in allows to begin an interactive debug session in which even 
a tightly-bound microprocessor loop may be interrupted so 
as to permit analysis of the system state. 

On the other hand, if the 8-bit byte stored in step S2309 
does not request asynchronous break-in, then microproces- 
sor 173 simply stores the received byte and returns to step 
S2303 in which it resumes execution of ongoing processes 
that had been suspended in step S2304. Typically, other 
software modules active on microprocessor 173, such as 35 
CPSOCKET, monitor the data buffer into which the 8-bit 
byte has been stored. For example, by a previously-arranged 
convention, it might be determined that transmission of the 
character sequence "DNLD" signifies a request for down- 
load services in which a new software -module or modules 40 
are downloaded over the serial port connector 600. In such 
an instance, CPSOCKET might be arranged so as to echo 
each of the "DNLD" characters as they are received and 
thereafter to enter a download mode. 

FIG. 24(a) shows flow processing in the transmit mode of 45 
the software serial port, and FIG. 24(b) shows signals 
appearing at transmit terminal 602 in connection with trans- 
mit bits written into transmit register 524. 

In step S2401, microprocessor 173 writes a binary 1 start 
bit to the transmit bit in transmit register 524. The transmit 50 
bit, since it is connected to transmit terminal 602, causes a 
+5 voltage level to appear at transmit terminal 602. 

Flow then advances to step S2402 in which NEB micro- 
processor 173 waits a predetermined serial transmission 
period which, at a serial rate of 19.2 KHz corresponds to 55 
1/19.2-52 /*s (one inter-bit time). After waiting the required 
period, microprocessor 173 writes the first bit in the trans- 
mitted word to the transmit bit in transmit register 524 (step 
S2403). Until all eight bits of the transmitted word have 
been written (step S2404), microprocessor 173 repeats steps 60 
S2402 and S24Q3 in which it waits for the serial transmis- 
sion period and writes a next data bit to the transmit bit in 
transmit register 524. After all eight bits have been written, 
flow advances to step S2405 which, after waiting for the 
inter-bit transmission period, writes a stop bit to register 524, 65 
and then to step S2406 at which point serial transmission is 
complete. 



The invention has been described with respect to a 
particular illustrative embodiment. It is to be understood that 
the invention is not limited to the above described embodi- 
ment and that various changes and modifications may be 
made by those of ordinary skill in the art without departing 
from the spirit and scope of the invention. 

What is claimed is: 

1. A reprogrammable network communication device 
which communicates on a network, comprising: 

a reprogrammable read only memory which stores a 
current program image, a current network information 
file block containing current configuration information 
for the network communication device, and a software 
reprogramming module for reprogramming said repro- 
grammable read only memory, the current configura- 
tion information including current network media con- 
figuration information which specifies a medium type 
of the network; 

a random access memory which stores a new program 
image for said reprogrammable read only memory; and 

a processor which sends and receives network 
communications, which confirms that operation of the 
new program image is compatible with the medium 
type specified in the current configuration information 
in the current network information file block, and 
which executes the software reprogramming module so 
as to reprogram the reprogrammable read only memory 
with the new program image in a case where compat- 
ibility is confirmed. 

2. A reprogrammable network communication device 
according to claim 1, wherein the new program image 
includes a new network information file block, and wherein 
said processor replaces at least a part of the new network 
information file block with corresponding parts of the cur- 
rent network information file block before executing the 
software reprogramming module. 

3. A reprogrammable network communication device 
according to claim 2, wherein the new program image is 
downloaded to the network communication device over the 
network. 

4. A reprogrammable network communication device 
according to claim 3, wherein the current configuration 
information in the current network information file block 
includes a media access control (MAC) address. 

5. A reprogrammable network communication device 
according to claim 4, wherein said processor confirms 
compatibility of the new program image by comparing the 
current network media configuration information in the 
current network information file block with new network 
media configuration information in the new network infor- 
mation file block. 

6. A reprogrammable network communication device 
according to claim 4, wherein the current configuration 
information in the current network information file block 
includes host interface configuration information, and 
wherein said processor confirms compatibility of the new 
program image by comparing the host interface configura- 
tion information in the current network information file 
block with host interface configuration information in the 
new network information file block. 

7. A reprogrammable network communication device 
according to claim 4, wherein the current configuration 
information in the current network information file block 
includes product configuration information, and wherein 
said processor confirms compatibility of the new program 
image by comparing the product configuration information 
in the current network information file block with product 
configuration information in the new network information 
file block. 
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8. A reprogrammable network communication device 16. A method according to claim 13, wherein the current 
according to claim 4, wherein the current configuration configuration information in the current network informa- 
information in the current network information file block tion file block includes product configuration information, 
includes processor configuration information, and wherein and wherein compatibility of the new program image is 
said processor confirms compatibility of the new program 5 confirmed by comparing the product configuration informa- 
image by comparing the processor configuration informa- tion in the current network information file block with 
tion in the current network information file block with product configuration information in the new network infor- 
processor configuration information in the new network ma tion file block. 

information file block. 17. A method according to claim 13, wherein the current 

9. A reprogrammable network communication device ]Q configuration information in the current network informa- 
according to claim 4, wherein the current configuration tion file block includes processor configuration information, 
information in the current network information file block an d wherein compatibility of the new program image is 
includes memory configuration information, and wherein confirmed by comparing the processor configuration infor- 
said processor confirms compatibility of the new program ma tion in the current network information file block with 
image by comparing the memory configuration information processor configuration information in the new network 
in the current network information file block with memory 15 inf orma tion file block 

configuration information in the new network information 18. A method according to claim 13, wherein the current 

k ° A . , c . configuration information in the current network informa* 

10_ A method for reprogramming a network commumca- * e bIock ;nc , udes m configuration information, 

tion device which communicates on a network, comprising , , . c iL 

the ste s of ■ 20 wherein compatibility of the new program image is 

4 . . ' ii « | , confirmed by comparing the memory configuration infor- 

storing in a reprogrammable read only memory device a . . ' . . i • r ci li 1 -.i. 

current program image, a current network information matl0n 1D th fi e current network mformation file block with 

file block containing current configuration information memory configuration information in the new network infor- 

for the network communication device, and a software mation file block. 

reprogramming module for reprogramming the repro- 25 19 * Computer-executable process steps stored on a 
grammable read only memory, the current configura- computer-readable medium, the process steps to reprogram 
tion information including current network media con- a network communication device which communicates on a 
figuration information which specifies a medium type network, said computer-executable process steps compris- 
of the network; ing: 
storing in a random access memory a new program image 30 code to store in a reprogrammable read only memory 
for the reprogrammable read only memory; device a current program image, a current network 
confirming that operation of the new program image is information file block containing current configuration 
compatible with the network medium type specified in information for the network communication device, 
the configuration information in the current network anci a software reprogramming module for reprogram- 
information file block; and 35 ming the reprogrammable read only memory, the cur- 
executing the software reprogramming module so as to reDt configuration information including current net- 
reprogram the reprogrammable read only memory with work media configuration information which specifies 
the new program image in a case where compatibility a medium tv P c of lne network; 
is confirmed. code to store in a random access memory a new program 

11. A method according to claim 10, wherein the new 40 ima S e for lne reprogrammable read only memory; 
program image includes a new network information file code to confirm that operation of the new program image 
block, and further comprising the step of replacing at least is compatible with the network medium type specified 
a part of the new network information file block with in the configuration information in the current network 
corresponding parts of the current network information file information file block; and 

block before execution of the software reprogramming mod- 45 code to execute the software reprogramming module so as 

ule. to reprogram the reprogrammable read only memory 

12. A method according to claim 11, further comprising with the new program image in a case where compat- 
the step of downloading the new program image to the ibility is confirmed. 

network communication device over the network. 20. Computer-executable process steps according to claim 

13. A method according to claim 12, wherein the current 50 19, wherein the new program image includes a new network 
configuration information in the current network informa- information file block, and further comprising code to 
tion file block includes a media access control (MAC) replace at least a part of the new network information file 
address. block with corresponding parts of the current network 

14. A method according to claim 13, wherein compatibil- information file block before execution of the software 
ity of the new program image is confirmed by comparing the 55 reprogramming module. 

current network media configuration information in the 21. Computer-executable process steps according to claim 

current network information file block with new network 20, further comprising code to download the new program 

media configuration information in the new network in for- image to the network communication device over the net- 

mation file block. work. 

15. A method according to claim 13, wherein the current 60 22. Computer-executable process steps according to claim 
configuration information in the current network informa- 21, wherein the current configuration information in the 
tion file block includes host interface configuration current network information file block includes a media 
information, and wherein compatibility of the new program access control (MAC) address. 

image is confirmed by comparing the host interface con- 23. Computer-executable process steps according to claim 

figuration information in the current network information 65 22, wherein compatibility of the new program image is 

file block with host interface configuration information in confirmed by comparing the current network media con- 

the new network information file block. figuration information in the current network information 
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file block with new network media configuration informa- 
tion in the new network information file block. 

24. Computer-executable process steps according to claim 
22, wherein the current configuration information in the 
current network information file block includes host inter- 
face configuration information, and wherein compatibility of 
the new program image is confirmed by comparing the host 
interface configuration information in the current network 
information file block with host interface configuration 
information in the new network information file block. 

25. Computer-executable process steps according to claim 
22, wherein the current configuration information in the 
current network information file block includes product 
configuration information, and wherein compatibility of the 
new program image is confirmed by comparing the product 
configuration information in the current network informa- 
tion file block with product configuration information in the 
new network information file block. 

26. Computer-executable process steps according to claim 
22, wherein the current configuration information in the 
current network information file block includes processor 
configuration information, and wherein compatibility of the 
new program image is confirmed by comparing the proces- 
sor configuration information in the current network infor- 
mation file block with processor configuration information 
in the new network information file block. 

27. Computer-executable process steps according to claim 
22, wherein the current configuration information in the 
current network information file block includes memory 
configuration information, and wherein compatibility of the 
new program image is confirmed by comparing the memory 
configuration information in the current network informa- 
tion file block with memory configuration information in the 
new network information file block. 

28. A computer-readable medium which stores computer- 
executable process steps, the computer-executable process 
steps to reprogram a network communication device which 
communicates on a network, the computer-executable pro- 
cess steps comprising: 

a first storing step to store in a reprogrammable read only 
memory device a current program image, a current 
network information file block containing current con- 
figuration information for the network communication 
device, and a software reprogramming module for 
reprogramming the reprogrammable read only 
memory, the current configuration information includ- 
ing current network media configuration information 
which specifies a medium type of the network; 

a second storing step to store in a random access memory 
a new program image for the reprogrammable read 
only memory; 

a confirming step to confirm thai operation of the new 
program image is compatible with the network medium 
type specified in the configuration information in the 
current network information file block; and 

an executing step to execute the software reprogramming 
module so as to reprogram the reprogrammable read 
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only memory with the new program image in a case 
where compatibility is confirmed. 
29. A computer-readable medium according to claim 28, 
wherein the new program image includes a new network 
5 information file block, and further comprising the step of 
replacing at least a part of the new network information file 
block with corresponding parts of the current network 
information file block before execution of the software 
reprogramming module. 
30 30. A computer-readable medium according to claim 29, 
further comprising a downloading step to download the new 
program image to the network communication device over 
the network. 

3S 31. A computer- readable medium according to claim 30, 
wherein the current configuration information in the current 
network information file block includes a media access 
control (MAC) address. 
32. A computer-readable medium according to claim 31, 

20 wherein compatibility of the new program image is con- 
firmed by comparing the current network media configura- 
tion information in the current network information file 
block with new network media configuration information in 
the new network information file block. 

25 33. A computer-readable medium according to claim 31, 
wherein the current configuration information in the current 
network information file block includes host interface con- 
figuration information, and wherein compatibility of the new 
program image is confirmed by comparing the host interface 

30 configuration information in the current network informa- 
tion file block with host interface configuration information 
in the new network information file block. 

34. A computer-readable medium according to claim 31, 
wherein the current configuration information in the current 

35 network information file block includes product configura- 
tion information, and wherein compatibility of the new 
program image is confirmed by comparing the product 
configuration information in the current network informa- 
tion file block with product configuration information in the 

40 new network information file block. 

35. A computer-readable medium according to claim 31, 
wherein the current configuration information in the current 
network information file block includes processor configu- 
ration information, and wherein compatibility of the new 

45 program image is confirmed by comparing the processor 
configuration information in the current network informa- 
tion file block with processor configuration information in 
the new network information file block. 

36. A computer-readable medium according to claim 31, 
50 wherein the current configuration information in the current 

network information file block includes memory configura- 
tion information, and wherein compatibility of the new 
program image is confirmed by comparing the memory 
configuration information in the current network informa- 
55 tion file block with memory configuration information in the 
new network information file block. 

***** 



03/01/2004, EAST Version: 1.4.1 



mi ii jiii yi iiimiroDUi iniaiui i n m n i n m 



United States Patent [wj 

Kalwitz et al. 



US005815722A 

[ii] Patent Number: 
[45] Date of Patent: 



5,815,722 
Sep. 29, 1998 



[54] IN AN INTERACTIVE NETWORK BOARD, A 
METHOD AND APPARATUS FOR 
REMOTELY DOWNLOADING AND 
EXECUTING FILES IN A MEMORY 

[75] Inventors: George A. Kalwitz, Costa Mesa; 

William C. Russell, Laguna Hills; H. 
Brad Emerson, Costa Mesa; Natsuko 
TakahashI, Long Beach, all of Calif. 

[73] Assignee: Canon Information Systems, Inc., 
Irvine, Calif. 

[21] Appl. No.: 978,488 

[22] Filed: Nov. 18, 1992 

[51] Int. CI. 6 G06F 13/10 

[52] U.S. CI 395/712; 395/200.3 

[58] Field of Search 395/600, 325, 

395/700, 115, 200, 200.1, 712, 200.3 

[56] References Cited 

U.S. PATENT DOCUMENTS 

4,441,164 4/1984 Pavan et al 395/115 

4,724,521 2/1988 Carron et al 395/712 

4,742,483 5/1988 Morrell 395/112 

4,866,664 9/1989 Burkhardt, Jr. et al 395/200.57 

4,974,199 11/1990 Verbanets, Jr. et al 395/837 

5,007,013 4/1991 Elms 395/200.83 

5,018,079 5/1991 Shukunami et al 395/106 

5,019,963 5/1991 Alderson et al 707/201 

5,048,771 9/1991 Siering 244/3.15 

5,075,875 12/1991 Love et al 395/117 

5,146,568 9/1992 Flaherty et al 395/500 

5,155,847 10/1992 Kirouac et al 395/200.51 

5,239,621 8/1993 Brown, III et al 395/115 

5,287,455 2/1994 Rosenthal 395/200.83 

5,299,314 3/1994 Gates 395/884 

5,317,690 5/1994 Krzycki 364/420 

5,388,211 2/1995 Hornbuckle 395/712 

5,424,524 6/1995 Ruppert et al 705/8 

5,444,861 8/1995 Adamec et al 395/712 



FOREIGN PATENT DOCUMENTS 



036172 
464988 



9/1981 
1/1992 



European Pat Off. . 
European PaL Off. . 



OTHER PUBLICATIONS 



"A Simple High-Speed Optical Local Area Network Based 
on Flooding*', Moshen Kavehrad, IEEE Journal on Selected 
Areas in Communications, vol. 6, No. 6, Jul. 1988, pp. 
944-949. 

"Boot Mechanism for Discless HP-UX", Perry E. Scott, et 
al., Hewlett-Packard Journal, vol. 39, No. 5, Oct. 1988, pp. 
33-36. 

"Format To Hex Code To Object Code With Computed 
Checksum*', IBM Technical Disclosure Bulletin, vol. 31, 
No. 3, Aug. 1988, pp. 491^92. 

Primary Examiner — Parshotam S. Lall 

Assistant Examiner — Kenneth Coulter 

Attorney, Agent, or Firm — Fitzpatrick, Cella, Harper & 

Scinto 



[57] 



ABSTRACT 



Method and apparatus for altering an executable file stored 
in a random access memory on a designated interactive 
network having a local area network interface comprises 
activating a LAN communication program. The communi- 
cation program operates to broadcast an inquiry through the 
local area network for the designated interactive network 
board, to receive location information of the designated 
interactive network board in response to the broadcast 
inquiry, and to establish communication with the designated 
interactive network board. The executable file is down- 
loaded into RAM on the designated interactive network 
board through the local area network interface. A verifying 
step verifies a checksum value of the executable file against 
a checksum value in a checksum packet attached to the 
executable file. In the case that the verifying step is suc- 
cessfully completed, execution of the executable file may be 
commanded remotely, e.g., across the LAN interface. 

29 Claims, 31 Drawing Sheets 
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IN AN INTERACTIVE NETWORK BOARD, A by a manufacturer's representative in order to have this 

METHOD AND APPARATUS FOR function performed. For example, conventional printers 

REMOTELY DOWNLOADING AND store executable programs in ROM. These executable 

EXECUTING FILES IN A MEMORY programs, which affect the manner in which ajTimage isTo 

5 be'folroedi are unalterable by the customer. Thus, if it is 

BACKGROUND OF THE INVENTION deTeTmined, after the product has been shipped to the 

1. Field Of The Invention customer, that there is a problem in the executable software, 

Hie present invention relates generally to a circuit board the manufacturer either has to recall the printer or must send 

which is coupled to a local area network peripheral (e.g. a a * er y ice representative out to the location of the printer at 

printer) and which allows the peripheral to be an intelligent, 10 wmch P omt Clth ^ r a ° U P date °* SoftWare pr0gram 0r a 

interactive network member eliminating the necessity of new Programmed chip is installed, 

dedicating a personal computer to manage the peripheral. Heretofore, it has not been possible to remotely alter the 

More particularly, the present invention relates to a method executable files within a computer or peripheral device 

and apparatus for downloading executable files to a random through a local area network from a remote LAN device, 

access memory (RAM) from a remote local area network 15 That is, a computer or a peripheral device could not be 

device, and remotely executing the downloaded files upon accessed through the LAN in order to alter or add additional 

receiving a command from the remote LAN device. executable files, and in addition, to receive remote com- 

2 Related Art mands through the LAN to execute the altered executable 

' . . - T . /WT-..VT-..X-- * — — A files or newly added files. Consequently, software updates 

^Local Area Networks ( LANs ) are known for coupling}-,, , . J . C1 . n r , . 

h a lu lit f onajcom uters^with — en teral and added executable files must be performed by the m ami - 

i^^.^^_^?^..^L^.~y^^^J^^? li 4 ^S^ n P e ?f e 5 a facrurer or at the customer's site by a service representative 

devices such as printers, copiers, etc., to provide for . . , , , *\ r 

, • j 1 j a t c which is not only inconvenient, but expensive, 

enhanced communication and shared resources. Heretofore, J 

peripherals such as printers coupled to a LAN were rather SUMMARY OF THE INVENTION 

unintelligent, merely accepting information from the LAN 25 ^ presem ^ uiioix overcomes the drawbacks noted 

and printin g such information on a hard cop y. Moreove r, above by providing struct ure and function on a circuit board 

such printers usually required a host personal computer coupled tQ a peripheral which will ^ the peripheral to 
("PC") to effectively manage the flow of data_to the printer^ be a responsive, intelligent member of a network, 

i.e., to act as a "server" for the printer. This almost always . *r,u t • t - *uir 

* j i_ . . ™ * . f. , i i * *l • / In one aspect of the present invention, a method for 

required that the host PC be dedicated solely to the printer in , , j- . ui ci * u * j- n A »i 

^ . J r 30 downloading an executable file to be stored in a RAM on a 
server task 

designated interactive network board is provided whereby a 

A number of products have recently appeared which remote LAN device downloads the executable file through a 

ostensibly eliminate the need for such a dedicated PC by interface on the interactive network board, and 
incorporating har^re^andjoftware into a circuit board^ remotcly commands the interactive network board to 

which may be coupled into the peripheral in order to perform 35 execute the downloaded file. According to this aspect of the 

limited server functions. For example, ASP Computer invention/a^th^d 1673^ 

Products, Inc. provides a device known as "JetLAN/P" stored^rra RAM on a designatedlnteractive network boari 

which acts as a stand-alone print server for Novell networks. ; having area.networkinterface compriscTihVstep of 

The JetLAN/P® device couples to a LAN using a 10Base-2 ac jfr ating a communication program. The communi- 

thin coaxial cable or a lOBase-T twisted-pair cable. 40 cat ion program operates to broadcast an inquiry through the 

However, the JetLAN/P® couples to the printer only local area Qetwork for the designated interactive network 

through the printer's parallel port. Thus, while print infer- board> t0 rece ive-location information of-the~desighated ; 

mation can be sent to the printer, the amount of printer status rinteractive-nefwork - board in response - c to the broadcast 

information which can be returned from the printer is finquiryTandnd'esta^^^ 

severely restricted. For example, such a device may obtain 45 \hteractive network board. <The executable file ~is~ down-, 

"off-line" and "out of paper" status from the printer, but little <i oa ded into the RAM on the designated interactive network 

else. Such a dev 1C e does very little toward making the prmter board through the local area network interfaced verifying J> 

a truly intelligent, responsive member of the network. ^tep ven^eslfch^cl«nm value of the downloaded executable 

Other known devices for coupling a printer to a LAN Me^against a checksum value in Vchecksumyacket attached 

include the Hewlett-Packard Jet Direct® C2071A/B and 50 to the executable file. In the case that the verifying step is 

C2059A, the Extended Systems EtherFlex®, the Intel Net- successfully completed, the execution of the executable file 

Port® and NetPort II®, the Castelle LANPress® and ^ commanded from a remote LAN device. 

JetPress®, and the MILAN FastPort®. However, all of these According to another aspect of the invention, an apparatus 

devices suffer from the same disadvantages as the ASP for downloading an executable file to an interacUve.network 

JetLAN in that they do not allow the printer to transmit 55 board i nc i ud cs aRAM disposed on the interactive network^ 

sufficient amounts of data to the LAN to enable the printer rbdaTdJoTs^ file therein^ 

to be an effective and intelligent member of the network. lan mterfac^connected~to-thVim 

Conventionally, a manufacturer formats and stores f or receiving the downloaded executable file, and a proces- 

executable programs into a programmable memory within ^ for executing the downloaded executable file stored in 

computers and peripheral devices therefor. These executable 60 RAM. The processor executes the executable file in response 

programs generally are unalterable by^ the customer. to a command from a remote LAN interface. 
Therefore, :in the case these devices require an updated": 

fvereion of an executable program or if "iris determined that BR1EF DESCRIPTION OF THE DRAWINGS 

the executable filicides not operate properly and the devices The above-noted advantages and features of the present 

require servicing for the program, the executable program 65 invention will become more readily apparent from the 

within the computer or the peripheral device must be altered following detailed description of the preferred embodiments 

either at the site of manufacture or at the site of the customer when taken in conjunction with the Drawings in which: 
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FIG. 1 is a block diagram of a Local Area Network peripheral, such as a printer, an interactive netwo rk mem ber 

according to the present invention; capabl e not on ly of receiving^nd'processing data received^ 

FIG. 2 is a block diagram of a plurality of Local Area rfromTffielnetw^ to the network sig-\ 

Networks coupled together; ,njfi^nt,amojuntsj^ information/ 

FIG. 3 is a block diagram showing the Network Expan- 5 operational parameters, and even data inpurfo'the peripheral 

sion Board according to the present invention coupled through other modalities such as scanning, facsimile 

between the Local Area Network and the printer; reception, etc. By integrating such hardware and software 

FIG. 4 is a block diagram of the Network Expansion with f j^P*^ " * P^ible to eliminate the require- 

r» . j- • *u . ■ me nt for dedicating a personal computer to the peripheral to 

Board according to the present invention; act as a peripheral server. 

FIGS. 5 A, 5B and 5C comprise a top-level flowchart i° ^ ARCHITECTURE 

showing the basic functions of the Network Expansion p IG j ^ a b i ock diagram showing the present invention 

Board according to the present invention; incorporated into a Network Expansion Board ("NEB") 2 

FIG. 6 is a diagram showing the sequence in which coupled to a printer 4 which has an open architecture (to be 

software modules are loaded from the Network Expansion discussed below). The NEB 2 is coupled to the LAN bus 6 

Board ROM to RAM; 15 through a LAN interface 8, for example, Ethernet interfaces 

FIG. 7 is a block diagram showing hardware and software 10Base-2, lOBase-T, or 10Base-5, respectively, with a Coax 

interfaces between the LAN and the Network Expansion connector, an RJ45 connector, or a DB15 connector (AUQ^ 

g oarc j. Also coupled to the LAN 6 may be such^ejwork-members^^ 

n^' o- a u . u • u *u nTmrwM a as.PC^10rPC12, PC 14~(which in this case acts~as'the 

FIG. 8 is a flowchart showing how the EPROM firmware \ , • . . . f t , v , . . , , . . . 

o . f i - *l kt f t t> j • 20 network administrator if the administrator has logged in at 

isconfiguredforplacmgtheNetworkExpansionBoardinan ^ pC; tQ be discussed below)> and a printe *f 6 (with 

operational mode; embedded QSERVER functionality; also to be discussed 

FIG. 9 is a chart showing the physical construction of below). Other LAN members may include PC 18 (acting as 

different frame packets used on Ethernet; a pruit server; to be discussed below) with attached printer 

FIG. 10 is a flowchart showing the operation of a PRES- 2$ 20, PC 22 (acting as an RPRINTER; to be disc ussed b elow) 

CAN software module; with attached printer 24, and:printeT26"whlcrris > coupledjo_^> 

FIG. 11 is a chart showing that the PRESCAN module <th^LAFT6 through a NetPort device 28 (disc ussed i n the ^©*>*~^ 

may be used with other software protocols; Background of the Invention above). CA file server 

FIG. 12 is a chart for explaining the software structure of ^pled-ton^^ 

the SAPSERVER program* 30 ^ e tra nsmitted and processed onjhe ^LAN.>The~nle server 30 

™~ n . „ F _ \ tU t - pcatic may have attached printers 32 and 34. 

FRVFR 1S 3 ^ ° PCr In m ° re dCtai1 ' the netWOrk de P icted in FIG * 1 Utilize 

hRVhR; an y ne t wor k software such as Novell or Unix software in 

FIG, 14 is a flowchart showing the operation of a CPINIT order t0 eE f ect communication among the various network 

program; members. The present embodiments will be described with 

FIG. 15 is a flowchart showing the operation of a 35 respect to a LAN utilizing Novell NetWare® software (to be 

CPCONSOL program; discussed in greater detail in section 3a below) although any 

FIGS. 16A and 16B comprise a flowchart showing the network software may be used. A detailed description of this 

operation of a CPSOCKET program; software package may be found in the publications "Net- 

FIGS. 17A and 17B comprise a flowchart showing the ^® ^[\\^'\ a ° d lhe . 7^^? Su P ervisor '* 

automatic logging of peripheral statistics; 40 ? mde u b * ^&T Books, copyrighted I 990, incorporated 

1D • ri u ♦ u • u u- > 1 * herein by reference. See also the "NetWare® Print Server 

FIG. 18 is a flowchart showing how multi-tasking pro- by ^ NoveU par( Nq ^ 

CC ™ g ^- o J i_ ■ i_ L . 000892-001, Briefly, the file server 30 acts as a file manager, 

FIG. 19 is a flowchart showing how to place the printer in . . t . ' • . • n * aijZ^e 

. & F p receiving, stonng, queuing, caching, and transmitting ales or 

a sate, detault configuration; 45 data ^tween jj^ mem bers. For example, data files created 

FIG. 20 is a flowchart showing the downloading of respectivcly at lhe PCs 10 and 12 may be routed to the file 

executable files to the Network Expansion Board from the server 30 which may order lhose data mes and lhen transfer 

local area network; the ordered data gi es t0 a primer 24 upon command from a 

FIG. 21 is a flowchart showing the loading of print server in PC 18. The file server 30 may include or may 

independently-executable modules in the EPROM of the 50 be coupled to a large capacity storage member such as a 10 

Network Expansion Board; Gigabyte hard disk subsystem. Furthermore, the printers 32 

FIG. 22 is a block diagram showing Network Expansion and 34 may be coupled to the file server 30 to provide 

Board EPROM flash protection circuitry; additional printing stations, if desired. 

FIG. 23 is a flowchart showing the operation of the While personal computer equipment is illustrated in FIG. 

circuitry of FIG. 22; 55 1, other computer equipment may also be included, as 

FIG. 24 is a flowchart showing the operation of remotely appropriate to the network software being executed. For 

loading firmware in the Network Expansion Board EPROM; example, Unix workstations may be included in the network 

FIG. 25 is a block diagram showing a hardware configu- when Unix software is used, and those workstations may be 

ration for testing the Network Expansion Board; and used in conjunction with the illustrated PC's under appro- 

FIGS. 26A and 26B comprise a flowchart showing a 60 P riate circumstances, 

method of testing the Network Expansion Board using the PCs 10 and 12 ma y each comprise a standard work station 

test configuration of FIG. 25. PC capable of generating data files, transmitting them onto 

the LAN, receiving files from the LAN, and displaying 

DETAILED DESCRIPTION OF THE and/or proce ssing such files at the work station. The PCs 10 

PREFERRED EMBODIMENTS 6S and ^ however, are not capable of exercising control over 

In its general aspects, the present invention provides LAN peripherals (unless the network administrator is logged 

hardware and software solutions for making a network into that PC). 
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A PC capable of exerting limited control over LAN 
peripherals is PC 22 which includes an embedded 
RPRINTER program. The RPRINTER program is a 
MS-DOS Terminate and Stay Resident ("TSR") program 
which runs on a work station to allow users to share the 
printer 24 connected to the work station. RPRINTER is a 
relatively unintelligent program that does not have the 
ability to search printer queues for work. RPRINTER gets its 
work from a PSERVER (to be discussed below) that is 
running elsewhere in the network. Because they communi- 
cate with the attached printer over the printer's parallel port, 
RPRINTERs are able to obtain only limited status and to 
return that status information to the responsible PSERVER 
over the LAN 6. From a control standpoint, an RPRINTER 
allows stopping of a print job and Little more. Some printers 
include RPRINTER features by offering internal or external 
circuit boards that provide the same limited features of the 
RPRINTER TSR program running in a personal computer. 

Another network entity capable of exercising limited 
control over LAN peripherals is a printer 16 with attached 
circuit board 36 having an embedded QSERVER program. 
Here, the QSERVER program runs inside an HP LaserJet 
III® SI printer, and has the capability of searching the file 
server 30 print queues for eligible print files. The QSERV- 
ER's search queues cannot be dynamically altered nor does 
the QSERVER respond to any form of status inquiry. The 
benefit of the QSERVER is its ability to autonomously 
search for work. The QSERVER does not require a 
PSERVER running elsewhere in the system to feed it work. 
Since the QSERVER does not have a corresponding 
PSERVER and it does not itself have any status and control 
capabilities, it offers less control than even the RPRINTER. 
A QSERVER also differs from a PSERVER in that it has 
extremely limited notification features and cannot print 
banners at the beginning of each print job. 

Another network member having a QSERVER capability 
is printer 26 which is coupled to the LAN 6 through an 
external NetPort device 28. 

Other peripheral server programs may be executed to 
service various peripherals, such as scanners, copiers, fac- 
similes etc., and servers may also be provided based on 
network software protocol such as a Unix -compatible Line 
Printer Remote server ("LPR"). 

A LAN member capable of exercising significant control 
over LAN peripherals is the PC 18 having a PSERVER 
program embedded therein. PSERVER has the ability to 
service multiple user-defined print queues, perform dynamic 
search queue modification, and provide defined notification 
procedures for exception (failure) conditions and status and 
control capabilities, PSERVER is provided in several forms. 
PSERVER.EXE is a program that runs dedicated on a work 
station and controls both local and remote printers. The local 
printers can be connected to either serial or parallel ports, 
and the remote printers are printers running elsewhere in the 
system. Two other forms of the PSERVER program are the 
PSERVER.VAP and the PSERVER. NLM. These are 
PSERVER versions that run on the file server 30 itself. The 
. VAP version is for NetWare® 286, and the .NLM version is 
for NetWare® 386. While the PSERVER provides much 
more capability than the RPRINTER and QSERVER, one of 
its drawbacks is that the .EXE version requires a dedicated 
personal computer. 

A dedicated personal computer running PSERVER.EXE 
can control as many as 16 local/remote printers and can 
request print information from many file server queues. 
However, there are several drawbacks to relying on 
PSERVER to control network printing services. The first 
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drawback is that multiple printer streams must all be fun- 
nelled through a single network node and personal computer 
processor. This can become a bottleneck. The second draw- 
back is that for the most efficient operation, the printers 
should be connected to the computer locally, as with the 
printer 20. This can be an inconvenience for users since it 
requires the printers to be clustered around PC 18. The third 
drawback is that if the controlled printers are remote as in 
the case of printer 24 which is serviced by RPRINTER, then 
the print data must make the trip from the file server 30 to 
the PSERVER PC 18 and then be retransmitted to the printer 
running RPRINTER. This is inefficient. 

The fourth drawback is the limited amount of printer 
status and control information offered through PSERVER. It 
has already been stated that RPRINTER does not allow for 
much more than rudimentary status such as "out of paper" 
and "off fine". PSERVER itself for locally and remotely 
connected printers does not offer much more than this 
because it was designed with consideration of the limitations 
of the personal computer parallel port. The PSERVER 
program also allows for its own status and control. 

The Network Expansion Board 2 installed in the printer 4 
provides many advantages and enhanced flexibility over the 
network peripheral control entities discussed above. In 
particular, the NEB-embedded controller offers RPRINTER, 
PSERVER and LPR (Line Printer Remote) functionality 
(through CRPRINTER, CPSERVER and CLPR programs to 
be discussed in section 3d below). There is an initialization 
program named CPINIT (to be discussed in section 4h 
below) which allows the network administrator's PC 14 
complete control over the configuration of NEB features. 
Due to its embedded nature and the open architecture of 
printer 4, the NEB will have the ability to offer a wide 
variety of status and control features to the network. That is, 
verbose amounts of status information may be provided 
from the printer 4 to the LAN 6, and a great deal of control 
information may be provided from the LAN 6 to the printer 
4 (for example, exercising printer front panel functions from 
the PC 14). 

To access the extended amount of information available in 
the NEB, a program called CPCONSOL is resident in the 
network administrator's PC 14 and allows the system 
administrator to view all of the printer information which is 
exported from the printer 4 by the NEB 2. The printer 
information is available even if the RPRINTER functional 
configuration (CRPRINTER) of the NEB 2 is selected. The 
PSERVER functional configuration (CPSERVER) of the 
NEB 2 will control the printer 4 that contains the board. This 
option will have all of the standard PSERVER queue search 
capabilities as well as the notify and status features. All of 
these features can be dynamically controlled from a remote 
work station. The NEB environment and its ability to export 
extended status and control information from the printer 4 
makes the combination of the NEB 2 and the printer 4 much 
more powerful than the standard RPRINTER, QSERVER, 
or PSERVER print methodologies currently available. 

The CPCONSOL program (to be discussed in greater 
detail in section 4i below) provided in the network admin- 
istrator's PC 14 is capable of interfacing with the NEB 2 
(and other network members) to perform such functions as 
displaying current information for a selected network device 
(interface information, control information, font 
information, layout information, quality and common envi- 
ronment information, duplex information, and miscella- 
neous information). CPCONSOL is also capable of setting 
or modifying the safe (default) condition of a network 
device. CPCONSOL may also activate or deactivate appli- 
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cations of the NEB 2 such as CPSERVER or CRPRINTER 
(to be discussed below, but generally similar to the 
PSERVER and RPRINTER software packages discussed 
above). Furthermore, the CPCONSOL enables the PC 14 to 
display a log file, clear the log file, or write the log file to 5 
memory such as a local or a file system disk. CPCONSOL 
can also display such printer-related information on PC 14 
as the number of jobs, the number of pages per job, the 
number of pages per minute, the time per job, the number of 
total pages per day, the number of total jobs per day, and the 10 
number of days. The CPCONSOL program is also capable 
of displaying on the PC 14 such network-related information 
as media related and non-media related information, and of 
clearing such network statistics. 

The CPINIT program (to be discussed in greater detail in 15 
section 4h below) resident in the network administrator's PC 
14 can set up application information print services such as 
CPSERVER and CRPRINTER and configure those appli- 
cations. CPINIT is also capable of setting and/or displaying 
device information such as time/date/time zone, buffer size, 20 
disk size, logging flag, log limit, and a safe (default) 
environment flag. CPINIT can also restore default service 
headings, reset the NEB 2, reboot the NEB 2, command a 
font download, command an emulation download, display a 
NEB power-on-self-test ("POST") error, display the NEB 2 25 
firmware level, display the current log file size, etc. 

By providing the NEB 2 with PSERVER and RPRINTER 
capabilities, the present invention achieves, with a single 
circuit board, enhanced functionality for the printer 4 with 
respect to the LAN 6. Therefore, the printer 4 is a true 30 
"networked" printer and not just a printer connected to a 
network. 

While the present invention offers unique advantages on 
the LAN 6, these advantages are also realized when the LAN 
6 is coupled to one or more other LANs in a Wide Area 35 
Network ("WAN"). FIG. 2 depicts such a WAN which 
includes a first LAN 41 including a server SI 40, PC's 42, 
44, and 46, and a printer 48. The server SI 40 is coupled to 
a backbone 50 over a bus 52. The backbone 50 is nothing 
more than an electrical connection between a plurality of 40 
buses. Also connected to the WAN is a second LAN 61 
comprising server S2 60, PC's 62, 64, and 66, and a printer 
68. Server S2 60 is coupled to backbone 50 over bus 54. 

The WAN may also include a remote LAN 71 comprising 
server S3 70, PC's 72, 74 and 76 and a printer 78. Since the 45 
LAN 71 is remote from the remainder of the system, it is 
coupled to backbone 50 through a bus 56, a transponder 
(which may include a modem) 58, and a communication line 
59. 

In such a WAN, assume that PC 42 is a PSERVER 50 
requesting the use of printer 78, If the printer 78 is equipped 
with a NEB according to the present invention, a direct 
communication link can be established between the PC 42 
and the printer 78 whereby job information can be sent to 
printer 78, and status and control information can be sent 55 
from printer 78 to the LAN 41. Therefore, the NEB accord- 
ing to the present invention achieves its enhanced function- 
ality even when installed in a peripheral coupled to a WAN. 

FIG, 3 is a block diagram depicting the connection of the 
NEB 2, according to the present invention, with the printer 60 
4 and the LAN 6. The NEB 2 is directly connected to the 
LAN 6 via LAN interface 101, and also to the printer 4 via 
a bi-directional interface, here a Small Computer System 
Interface ("SCSI") 100. The SCSI interface 100 is coupled 
to an SCSI bus 102 of the printer 4. 65 

The NEB can also service additional SCSI devices, such 
as other printers (RPRINTERs) or other peripherals, daisy- 
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chained on the SCSI bus using standard SCSI connectivity 
protocol. Also, the NEB may be used to drive other periph- 
erals across the LAN itself. 

The printer 4 is preferably an open-architecture printer 
including the SCSI bus 102 and SCSI interfaces 104 and 
106. Printer 4 also includes a processor 108 such as a 
REDUCED INSTRUCTION SET COMPUTER ("RISC") 
which communicates with a RAM Memory 110 and with a 
printing engine 112 which actually drives the printing 
mechanism. The RISC processor also communicates with 
NVRAM 111 for storing information which needs to be 
maintained between power cycles, such as user-defined 
information, and with ROM 113 from which RISC processor 
108 executes printer control. The printer 4 may also include 
a hard disk 114 capable of holding large amounts of data in 
a non-volatile way. Printer 4 also has a front panel display 
116, and a keyboard 115 for inputting control commands to 
the printer. 

Preferably, the printer 4 includes an open architecture 
which takes advantage of the bi-directional nature of the 
SCSI interface 100 to provide a great deal of status (and 
other) information from the printer 4 to the LAN 6 via the 
NEB, and also to allow fine control of the printer from a 
remote location. For example, such open architecture when 
used with the bi-directional SCSI interface permits most or 
all of the information on the front panel display 116 of 
printer 4 to be exported to a remote location, and also 
permits most or all of the control functions of the printer 
front panel keyboard 115 to be activated from the remote 
location. 

Briefly, the open-architecture printer 4 comprises four 
major subsystems: Communication; Job Pipe; Page Layout 
and Raster functions; and Systems Services, The Commu- 
nication subsystem handles the different communication 
devices and initiates the start of a job application. When the 
printer starts to receive data, the Communication subsystem 
sends the first part of the incoming data to each emulator for 
examination. The first emulator that can process the data 
becomes the Job Pipe driver. The system then constructs a 
Job Pipe to process the data (data flows into one end of the 
pipe, and page images flow out of the other end). This Job 
Pipe comprises many segments one of which is the Job Pipe 
driver. 

The Job Pipe subsystem has a Pipe driver segment (the 
application for an emulator) and input and output segments. 
The input and output pipe segments have at least two other 
segments: for input, source and source filter segments; and 
for output, an output filter and a data sink. The input segment 
of the Communication subsystem delivers the input data 
which can be supplemented by information from a file 
system. The Pipe driver processes input and supplemental 
data. It also generates imaging commands and page layout 
information that it sends to the output segment. The Pipe 
driver may store this information to the printer disk (if 
present). The output segment sends this data to the Page 
Layout and Raster subsystem. 

The Page Layout and Raster subsystem takes the imaging 
and page layout information and converts it to a raster image 
for the print engine 112. This section operates completely 
separately from Job Pipe. 

The System Services subsystem provides file system 
access, console access, font services, basic system services, 
and image generation services. Therefore, a printer 4 having 
such an open architecture will take full advantage of the 
intelligent, interactive NEB 2 to provide increased function- 
ality to the printer 4 and the entire network. 
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2. HARDWARE 

FIG. 4 is a block diagram of the NEB 2 showing the major 
components thereof. The NEB 2 is coupled to the LAN 6 
through network connectors 202, 203, and 204. Preferably, 
the connector 202 is an RJ45 capable of accepting a 
lOBase-T connection. The connector 203 may comprise a 
DB15 connector for accepting a 10Base-5 connection, while 
the connector 204 may be a simple Coax connector capable 
of accepting a 10Base-2 connection. All of the connectors 
202, 203, and 204 are coupled to a network controller 206 
(preferably an Ethernet Network Controller). However, the 
connector 204 is first coupled through a transceiver 208. 

Power is supplied to NEB 2 from a +5V power source in 
printer 4 through the printer expansion port 226. The +5V 
power is also provided to the power converters 210 and 212. 
The power converter 210 provides -9 V power to transceiver 
208, while the power converter 212 provides +12V power 
for "flashing" (loading; to be discussed in section 4q below) 
the EPROM 222. Also, the network controller 206 is 
coupled to an 8 KB static RAM 214. 

The heart of the NEB 2 is a microprocessor 216, prefer- 
ably an NEC V53. The microprocessor 216 is coupled to a 
serial port 218, currently used for testing. Also coupled to 
the microprocessor 216 are a 512 KB dynamic RAM 220, a 
256 KB flash EPROM 222, an SCSI controller 224 
(corresponding to SCSI interface 100 of FIG. 3) a printer 
expansion port 226, a diagnostics/failure LED 240, a 256 
Byte non -volatile RAM 228, a control register 230, and a 
PROM 232 which stores the Media Access Control 
("MAC") address which is the unique name for every 
EtherNet board. 

The architecture of the NEB 2 provides an advantage in 
that it has unique support features for administration and 
management of large, multi-area networks. These support 
features include, for example, printer control and status 
monitoring from a remote location on the network, (i.e., 
from the network administrator's office), automatic manage- 
ment of printer configuration after each print job to provide 
a guaranteed initial environment for the next user, and logs 
of printer usage statistics accessible across the network for 
characterizing printer workload and scheduling toner car- 
tridge replacement. A key parameter in the NEB design is 
the ability to access the printer control state from the NEB 
2 through a bi-directional interface, here the SCSI interface 
100, This allows the printer console information to be 
exported to the NEB or to an external network node for the 
programming of many useful printing support functions. 

Table 1 below provides a description of the functions, 
implementation, and operational notes with respect to the 
major hardware elements of NEB 2. 



TABLE 1 



Function 


Implementation 


Notes 


Network Controller 


National DP 83902 


With DP8392 Coax 


(206) 




Transceiver 


Ethernet Interfaces: 


10Base-2 (202) 


Coax connector 




lOBase-T (204) 


RJ45 connector 




10Base-5 (203) 


DB15 connector 






(AUt) 


Embedded Processor 


NEC V53 


16-bit/36Mhz MPU 


(216) 




with DMA, timers, 






Interrupts 


EPROM (Bash) 


256K Bytes 


Network program 


(222) 




code, board BIOS 






(Basic Input 






Output Subsystem), 






diagnostics 
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TABLE 1 -continued 



5 



20 



Function 


Implementation 


Notes 


NVRAM 


256 Bytes 


Printer 


(220) 




Installation 






Configuration an 






Network 


DRAM 


512K Bytes 


Code execution and 


(220) 


data buffering for 






exp.port 




on. isyics 


Buffering of 


(214) 




incoming Ethernet 






packets 


SCSI Controller 


NCR 53C90A 


30-pin, internal 


(224) 




I/F configuration 






with power 


MAC Address and 


32 Bytes 


Stores MAC address 


Hardware ID PROM 


and I lard ward ID 


(232) 




information 


Board Size 


100 mm x 125 mm 


Type 2 EXP- I/F 






PCB, double-sided 






SMT 


Power 


5vdc, 710 ma 


DC converter on 






board for Ethernet 






+12vdc/-9vdc 



Preferably, the NEB 2 is installed inside the printer 4 in 

25 an expansion or options slot. The NEB 2 is thus an embed- 
ded network node with the processing and data storage 
features described above. 

The microprocessor 216 implements a data link layer of 
network packet transmission and reception. Network data 

30 transfer overhead is minimized through the use of a dedi- 
cated static RAM packet buffer 214 managed directly by the 
network controller 206. The microprocessor 216 accesses 
blocks of SRAM packet data and network messages through 
the network controller 206, and moves them into the large 

35 DRAM memory 220. 

Blocks of print image data and control information are 
assembled by the microprocessor 216 for transmission to the 
printer 4 by the SCSI controller 224 using the SCSI transfer 
protocol of the printer expansion port. Likewise, printer 

40 status information is transferred from printer 4 back to the 
NEB 2 in SCSI block format. The SCSI controller 224 
operates concurrently with the network controller 206 for 
increased data throughput for overall NEB performance. 
The microprocessor 216 is preferably an NEC V53 chip 

45 which is a fast, highly-integrated microprocessor with a 
16-bit Intel-compatible processor in support of Direct 
Memory Access ("DMA"), interrupt, timers and DRAM 
refresh control. Data bus structure on the NEB 2 is imple- 
mented 16-bits wide to take advantage of the 8-Bit/16-Bit 

50 dynamic bus sizing during microprocessor I/O transfers. 
Control firmware and printing application software for the 
microprocessor 216 are stored on the NEB 2 in EPROM 
222. After power-on self-test, the firmware code is selec- 
tively moved to the higher-performance DRAM 220 for 

55 actual execution. Network and printer configuration param- 
eters are written into NVRAM 228 when the printer is first 
installed onto the network. Thus, NVRAM 228 allows the 
NEB software to recover the installation parameters after 
printer power has been cycled off and on. 

60 3. SOFTWARE 

Software for the LAN comprises a combination of net- 
work software, and NEB-customized software such as NEB- 
embedded software and software resident on the network 
administrator's PC. 

65 3a. Network Software 

In the present embodiment, NetWare® network software 
is used to manage interactions between nodes of a network 
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such that the client work stations can share and receive 
services from server nodes such as disk file servers, database 
servers, print servers, etc. NetWare® itself is a combination 
of software modules running on these server nodes and on 
each work station node. At least one file server may be 
provided in a Novell network. NetWare® runs as the oper- 
ating system for the PC of the file server to provide basic 
network core services and utilities. File servers can connect 
to more than one LAN by using up to four network interface 
cards (preferably Ethernet or Token Ring connections). In 
these configurations, "bridging" or "backbone" services are 
provided between a plurality of LANs, as shown in FIG. 2, 
such that resources, including printers, can be shared "inter- 
net" i.e., from one LAN to another. 

On work stations, NetWare® runs in cooperation with the 
work station operating system (DOS or OS/2) as a Net- 
Ware® "shell" of control software. This shell has the effect 
of extending the services of the workstation operating sys- 
tem onto the network to make network resources appear 
local to the work station. 

Novell PSERVER software has the job of controlling a 
group of printers (up to sixteen) in order to service printing 
requests from network nodes. Requests are structured in a 
form of print queues that are held on the network file server 
using network queue management services. Queue entries 
contain a list of files to be printed. The files contain data to 
be printed such as tabs, formfeeds, and other Printer 
Description Language ("PDL") commands. Several queues 
can be serviced by a single PSERVER. 

Standard Novell servers are available in different versions 
depending on the type of network node they are to execute 
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Novell NetWare® provides a number of print utilities to 
configure and control file server or work station-based print 
servers and their attached printers. The Novell program 
PCONSOLE is a menu-driven utility that allows a user (the 

5 printer console operator) to create a new print server, con- 
figure up to sixteen local or remote print ports, create print 
queues, assign queues to printers, and start/stop printer and 
server operations. 

30 3b. NEB -Customized Software 

The NEB 2 is bundled with software modules that imple- 
ment the full range of printing services offered by Net- 
Ware®. This includes external NetWare®-compatible mod- 

15 ules that execute on work station nodes of the network in 
addition to internal NetWare®-compatible modules running 
on the NEB 2 inside the printer. The specific NetWare®- 
compatible programs developed for use with the NEB 2 
(e.g., the customized CPSERVER and CRPRINTER pro- 

20 grams to be discussed below) are provided with the same 
general operational interfaces as standard printing modules 
from Novell so as to be familiar to Novell users and network 
administration personnel. The customized versions include 
functional extensions that make use of the open architecture 

25 of the printer 4 to enhance print service management across 
the network. 

Table 2 shows the functions, implementations, and opera- 
tional notes for the customized software developed for the 
NEB. 



TABLE 2 



Function 


Implementation 


Notes 


NEB-specific 


CPSERVER 


(92KB) 


Customized Print 


functions in NEB 






Server 


EPROM 


CRPRINTER 


(40KB) 


Customized Remote 








Printer 


NEB-to-Network 


CPSOCKET 


(30KB) 


Concurrent multi- 


communication in 






protocol operation 


NEB EPROM 








NEB Environment in 




(15KB) 


Monitor, loader, 


NEB EPROM 






POST, etc. 


Extensions to 


CPCONSOLEXE 




Remote Control & 


NetWare ® 




(180 KB) 


Stats, Auto- 


PCONSOLE for Printer 


CPINIT.EXE 




Reconfiguration, 


Control/Configuration 




(120KB) 


Print Job 


in Administrator's 






Logs/Statistics 



PC 14 



on. Print server programs can reside on the file server itself. 50 
A version of print server software may also be loaded on a 
stand-alone DOS station node to make that node a dedicated 
print server. 

By providing print server functionality (CPSERVER) to 
NEB 2 of the present invention, the NEB and attached 55 
printer will offer all the printing services of a standard 
Novell print server without the need for an attached PC. 

Printers themselves are considered to be either "local" or 
"remote". A local printer is one that is physically connected 
to the print server node. In the case of the NEB 2, the local 
printer is the printer housing the NEB. A remote printer is 60 
managed by RPRINTER programs running in the PCs they 
are connected to. RPRINTERs receive print data from 
PRINTSERVERS running elsewhere on the LAN. The NEB 
2 of the present invention can be provided with RPRINTER 
functionality (CRPRINTER) to offer its printer as a network 65 
remote printer. In this mode, it is fully compatible with 
standard versions of Novell print servers. 



3c. NEB-Embedded Software 

The software developed for the NEB 2 includes software 
embedded in the NEB and software loaded into the network 
administrator's PC 14. The NEB-embedded software pro- 
vides both the NetWare®-compatible node and NetWare®- 
compatible print services directly inside the printer 4 with- 
out the overhead of a workstation PC and [its DOS operating 
system. The NEB-embedded software comprises a plurality A 
of application rnodules A (CPSERVER, CRPRINTER, etc.), ' 
real-time service modules, network protocol stacks, and a 
MONITOR program which performs application switching, 
process extension, device semaphores, and shares buffer- 
pool management. The functionality of the NEB is deter- 
mined by the types of application modules and the number 
of protocol stacks of network layered communication soft- 
ware that are configured into the NEB 2. Interaction between 
the printer 4 and the network is coordinated by the MONI- 
TOR program which responds to real-time events while 
allocating NEB processing time to each application module 
on a multi -tasking basis. 
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The NEB software functions at two layers: a "run-time" 
or real-time layer; and a "soft-time" or applications layer. 
The run-time layer is comprised of components of NEB 
software that respond to microprocessor interrupts. This 
layer services devices such as a timer, queued data transfer 
requests from the SCSI port, or LAN data through the 
protocol stack routine, and the CPSOCKET(to be discussed 
in section 4j below) communication mechanism. 

The soft-time layer is arbited and controlled by the 
MONITOR program (to be discussed in section 41 below) 
which gets control of the NEB microprocessor 216 after all 
real-time events have been serviced. A non-preemptive 
(cooperative multi-tasking) approach is used to divide the 
processor between the various application modules that are 
loaded such that no one application module can preempt 
other modules by capturing the microprocessor. 

The NEB EPROM 222 contains up to 256 KB of appli- 
cation module programs and NEB initialization code. At 
power-up or during a programmed reset, the NEB 2 executes 
a POST from the EPROM 222 before selectively transfer- 
ring its EPROM code to NEB DRAM 220. If the POST is 
successful, the NEB 2 will load its protocol stacks and 
application modules into DRAM, and begin execution of its 
application modules. 

In its basic configuration, the NEB 2 contains NetWare® - 
compatible application modules comprising embedded ver- 
sions of two configurations: the Customized Remote Printer 
("CRPRINTER"); and the Customized Print Server 
("CPSERVER"). Preferably, the NEB acts in only one of 
these configurations at a time. Further, these application 
modules require that a network protocol stack be loaded and 
functioning within the NEB. 

When configured with RPRINTER functionality, the NEB 
operates its printer as a slave to an external print server using 
a CRPRINTER module. In this configuration, the NEB 
exports to the LAN only limited printer status information in 
emulation of what the standard Novell print server expects 
from a standard Novell RPRINTER. However, extended 
status information about the printer will still be available if 
the CPCONSOL utility (discussed above) is executed in the 
network administrator's PC 14. 

As mentioned above, the NEB 2 includes embedded 
software programs CPSERVER and CRPRINTER which 
enable the NEB to act with either PSERVER or RPRINTER 
functionality on the network. The customized NEB- 
embedded software which permits peripheral status and 
control information over the LAN is CPSOCKET (to be 
discussed in section 4j below). CPSOCKET runs on the 
NEB and monitors the LAN for communications addressed 
to both the NEB 2 and the attached printer 4. Further, 
CPSOCKET communicates with CPINIT and CPCONSOL 
when they are running, CPSOCKET will maintain a table of 
default settings for the device environment, download basic 
configuration information (fonts and emulations) at power- 
up, provide device information, statistics, and log informa- 
tion for CPCONSOL displays, and provide reset, reboot, and 
download capabilities, CPSOCKET will also be responsible 
for the configuration of the NEB 2. Further, CPSOCKET 
will configure and activate applications on the NEB at the 
request of CPINIT. CPSOCKET also insures that the correct 
protocol stacks are available for each configured application. 
CPSOCKET will handle the settings of the NEB 2 and the 
printer variables at the request of both CPINIT and CPCON- 
SOL. Finally, the download facility (e.g. the network admin- 
istrator's PC 14) will contact CPSOCKET to carry out any 
firmware downloading, such as flashing EPROM 222, that is 
required. 



Upon initialization, programs such as CPINIT and 
CPCONSOL will issue a Service Advertising Protocol 
("SAP") on the LAN looking for all network devices having 
the customized software of NEB 2. CPSOCKET will receive 
this broadcast signal and will respond, CPINIT or CPCON- 
SOL then establishes a special connection with CPSOCKET 
using a customized client socket. CPSOCKET will then post 
multiple listens and will provide client service transactions 
such as NEB control, device information, basic configura- 
tion information, application information, statistics, and 
logging. For example, CPINIT can request that an applica- 
tion be configured, and CPCONSOL can request that an 
already-configured application be activated or deactivated. 
CPSOCKET will insure that the appropriate option (protocol 
stack) is available and configured for an application before 
allowing the application itself to be configured. Within the 
NEB, the CPSOCKET operational module is always acti- 
vated. 

Additional print service applications may be utilized after 
loading further application modules into the NEB, for 
example, UNIX print services and associated protocol 
implementation. 

3d. PC-Resident Customized Software 

To further enhance the functionality of the NEB 2, cus- 
tomized software is also provided to the network adminis- 
trator's PC 14. For example, a Customized PCONSOLE 
("CPCONSOL"; to be discussed in greater detail in section 
4i below) utility provides extensions to Novell's PCON- 
SOLE printer utility to enable access to the powerful control 
and monitoring features of the open-architecture printer 4. 
For example, the following are typical status control infor- 
mation available to the network from the printer through the 
use of CPCONSOL: (A) status and control information such 
as online/offline, no response, time/date/time zone, 
language, offsets, error skip settings, timer, buzzer enable, 
toner low, paper full, paper counter, count since last service, 
paper out, paper jam; (B) font information such as primary, 
secondary, graphic set, scaling, rotation, elite; (C) layout 
information such as page orientation, line pitch, character 
40 pitch; (D) quality and common environment information 
such as number of copies, overlay, job complete, command 
mode, default paper size, current paper size; and (E) con- 
figuration information such as interface, buffer size, feeder 
select, duplex print, page stack order, etc. 

Furthermore, configuration data for the printer accessible 
to the network through the use of CPCONSOL includes: (A) 
network group information such as protocol type, the node 
name, the file server name, routing, POST error code, NEB 
firmware level, MAC address, server mode; and (B) printer 
group information such as safe (default) environment, font, 
disk present, disk size, initial environment, logging on/off, 
log file size, configured/nonconfigured, and net name. 
Additionally, logs can be kept of print job flow, print engine 
usage, and network behavior. Examples of such usage and 
statistical log entries include: (A) network group informa- 
tion such as receive statistics, transmit statistics, and non- 
media related information; (B) job entry information such as 
date/time/time zone, log- in (user's name), job name, pages, 
copy count, and print status; (C) initialization entry infor- 
mation; (D) error condition entry information; (E) clear log 
entry information; and (F) printer group information such as 
the number of jobs, pages/job, pages/minute, time/job, total 
pages/day, total jobs/day, number of days and total resets. 

CPCONSOL is a menu-driven DOS executable program 
whose function is to provide extensions to the Novell 
PCONSOLE printer utility. The CPCONSOL extension 
enables access to the additional control and monitoring 
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features of the open-architecture printer 4. These features even data input from the peripheral (such as image data input 

will enhance print service management across the network from a scanner). The NEB microprocessor processes infor- 

by allowing the network administrator's PC 14 to control mation on a multi-tasking basis (sequential but shared) 

and maintain the printer from a remote location. In summary, effectively parallel processing information received from the 

CPCONSOL is the utility that exports printer control fea- 5 network and information received from the printer. This 

tures to the network administrator, allows reconfiguration of multi-tasking processing insures that the NEB is responsive 

the safe (default) environment, and allows the network to both the network and the printer on a near real-time basus. 

administrator to view network and printer status, job J FIGS - 5A > 5B > a t Dd 5C comprise a top-level flowchart 

statistics, and a log of the previously-processed jobs and de P lctin S a notional sequence of events which may occur 

error conditions. CPCONSOL gathers the requested infer- 10 whe t n the ^ * f nd ! te associated sof ^ e 15 ™ £lled ui a 

, . t . * t . XT ™ . jj j a printer coupled to a local area network. Overall, the printer 

mation by commumcahng with the NEB-embedded soft- ^ informadon and fa |ed t0 the mB £ m h 

ware program module CPSOCKET a WHlirectional SCSI interface . ^ rinter may also have a 

Another customized software program resident on the ^ p0ft and/or a porl fof receiving print mfor . 

network administrator's PC 14 is Customized Peripheral mation from other ^ukcs. The NEB is connected to the 

Initializer ("CPINIT"; to be discussed in section 4h below) is printer via the bi-directional SCSI interface, the board 

which is also a menu -driven DOS executable program. The receiving printer information from the local area network. 

function of the program is to configure, reconfigure, and The board sends print jobs and printer status inquiries to the 

initialize the printer 4 attached to the NEB 2. printer over the SCSI interface, receives printer status from 

The CPINIT module will configure the NEB to act as a the printer over the SCSI interface, and reports printer status 

print server with one attached printer and specifies its 20 over the network. 

primary file server by which the NEB will determine which Where the NEB is coupled to a data generating device 

queues to service. CPINIT is the program that supervises all such as a scanner, the board is connected to the scanner 

like-customized devices on the LAN (e.g. other NEBs through the bi-directional SCSI interface and is coupled to 

installed in other open-architecture printers). CPINIT the network via the LAN interface. The board receives status 

accomplishes this task by communicating over the network 25 request information from the network and will pass this 

with other NEBs that reside within open- architecture periph- information to the scanner over the bi-directional interface, 

eral devices. CPINIT is used to configure each NEB with the The board will also receive the data generated by the scanner 

appropriate basic configuration information such as config- over the bi-directional interface, and will pass that data onto 

uring the NEB as CPSERVER or CR PRINTER. The basic the network over the LAN interface, 

configuration information comprises NEB environment set- 30 Illustrating a sequence of events which may occur when 

tings (including which print server applications are active), the NEB is installed in a printer, FIG. 5 A begins when power 

as we 11 as device environment options (e.g. a list of fonts and is applied to the NEB at Step SI. At Step S2, the NEB 

emulations to download printer initialization time), and executes a power-on-self-test ("POST") from EPROM 220. 

device default settings (such as the internal device time/ At Step S3, if the POST is successfully completed, the 

date/time zone, buffer size, disk and logging information, 35 process moves to Step S5 where the NEB EPROM 222 

and printer name). The CPINIT program also displays status operational code reads the network and printer configuration 

information about the NEB (such as the firmware level code from NVRAM 228. If the POST is not successfully 

loaded in the NEB and reports latent POST errors). accomplished at Step S3, a failure indication is logged at 

The CPINIT program will broadcast over the network to Step S4 and this information may be transmitted to the 

see which other customized devices are available on the 40 network over the LAN interface. An LED failure/diagnostics 

LAN. The NEBs attached to such other customized devices light on the NEB or printer may also be activated, 

will respond with their identification numbers, their device After the network and configuration code have been read 

types, and their configuration states. CPINIT will construct from NVRAM 228, the procedure advances to Step S6 

a list of these NEBs and devices that will be presented to the where the NEB EPROM operational code reads selected 

network administrator to allow their con-figuration or recon- 45 configuration modules, protocol stacks, housekeeping 

figuration. modules, etc., (e.g., the MONITOR multi-tasking module, 

A DOWNLOADER program may also be loaded into the CPSOCKET, CPSERVER, etc.) from EPROM 222, and 

network administrator's PC 14 to download executable files downloads the selected modules to DRAM 220. In Step S6, 

to the NEB across the network (to be discussed in greater a configuration is selected (in accordance with the configu- 

detail in section 4n below). 50 ration set by CPINIT) which defines an operational mode 

Another customized program which may run on the (e.g. CPSERVER or CRPRINTER) of the interactive net- 
network administrator's PC 14 is CPFLASH which may be work board. As will be discussed in greater detail in section 
used to remotely flash new firmware into EPROM 222, as 4d below, a binary configuration code is sent over the LAN 
will be discussed in greater detail in section 4q below. and stored in NVRAM 228. After the NEB is booted up, the 
4. OPERATION 55 configuration code is read from NVRAM using ROM- 

At first, an overview discussion of the NEB structure and resident power-up process steps. Using the ROM-resident 

functions will be provided with respect to the flowchart of process steps, ROM-resident executable modules are 

FIGS. 5 A, 5B and 5C Thereafter, more detailed descriptions selected in accordance with the configuration code read from 

of various aspects of the NEB hardware and software will be NVRAM. The modules are selected in bit- wise correspon- 

provided with respect to sections 4a to 4q. 60 dence to the binary digits of the configuration code in 

The present invention takes advantage of the NVRAM. The selected modules are then stored into DRAM 

bi-directional nature of the communication between the and execution control for the modules is passed to DRAM 

printer and the NEB, and the NEB's ability to process whereupon the selected modules are executed. In this 

information on a multi-tasking basis. That is, the manner, multiple configurations can be defined and selec- 

bi-directional SCSI bus can transmit large quantities of data 65 lively changed. 

both to and from the printer, enabling the NEB to receive At Step S7, the EtherNet frame type of the information 

large quantities of specific status data from the printer or packets transmitted on the LAN is determined (as will be 
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discussed in greater detail in section 4e below). That is, identities. Thus, the NEB and attached printer can function 

EtherNet supports four different frame types: EtherNet in its twin roles of PSERVER and customized entity 

802.3; EtherNet II; EtherNet 802.2; and EtherNet SNAP. To (CPSOCKET; i.e., similar to other LAN peripherals having 

determine the EtherNet frame type, a pre-scan process a NEB installed therein). SAPSERVER is a NEB-resident 

("PRESCAN") determines what frame type is resident on 5 TSR program that allows more than one server to advertise 

the LAN (from any LAN broadcast data), and configures the net ^ t ^ 1CeS J ^*i\™r} l ™° n , the same L Dode * Thus » 

appropriate NEB-resident protocol stack for that data. The ? S0 ^ T DC a ^Hn ER Y ER ^ ^ 

pre-scan process strips away bytes of data from a received ih ™& SAPSERVER and respond to inquiries from other 

LAN packet until the bytes which indicate frame type are ne work Sin £ Ta P ^b ° i . * "?- ft £ 

u j r> • a e* ci j *u xicd *«u *i» only one SAP socket number, SAPSERVER will function to 

reached Briefly, Step S7 provides the NEB with the capa- 10 bolh ^ confusioQ {Q ^ ^ 

bility of processing LAN packets of different frame types by: In summary> Step sl3 ^ a method of identi f ying a sing ie 

receiving from the LAN a frame of data, pre-scanmng the interactive network board as two network (e . g . 

frame to determine the frame type, and processing, on the CPSERVER and CPSOCKET) comprising the steps of 

NEB, the identified frame, using an appropriate processing transmitting to the network at a predetermined time interval 

program. The pre-scanning operation includes the sub-steps is a s i gna i indicating that the board is a first type of network 

of stripping a predetermined number of bytes from the head entity, the signal including an identification signal unique to 

of the frame, processing the stripped frame to identify an the board; then, transmitting a second signal to the network 

identification code indicative of the frame type, and trans- at the predetermined time interval to indicate that the board 

mitting the identified frame to the processing program. is a second type of network entity, the second signal also 

At Step S8, a timer module which was downloaded in 20 including the same unique identification signal. Once a 

Step S6 finds the nearest LAN server and requests the signal is received from the network requesting that the board 

current time. After receiving the current time, the process perform functions of one of the types of network entities, 

proceeds to Step S9 where it is determined whether it is direct communication is established between the board 

midnight, i.e. whether the returned time indicates a new (acting as the requested type of network entity) and the 

date. 25 network entity which generated the request. When the direct 

Steps S9 through S12 comprise a so-called "autologging" communication is established, the NEB will utilize a new 

function which is carried out in the NEB by the CPSOCKET unique identification signal. 

program in order to automatically and systematically pro- At Step S14, both the LAN and the SCSI interfaces are 
vide status information from the printer to the LAN checked for data that is being directed to CPSOCKET (to be 
(autologging will be discussed in greater detail in section 4k 30 discussed in greater detail in section 4j below). The SCSI 
below). In Step S9, if midnight has not been reached the interface will typically have printer status data which is to be 
procedure advances to Step S13. However, once midnight is passed to the LAN in response to a previously-received 
reached, the NEB microprocessor 216 transmits a request to request for status. CPSOCKET is the NEB-resident TSR 
the printer over the SCSI bus for the printer to return current program that responds to such requests for connection, 
status to the NEB. For example, the printer may return the 35 requests for data download, or requests for services from 
cumulative number of pages printed to the NEB. In Step remote utilities. CPSOCKET gathers information from the 
Sll, the NEB microprocessor 216 calculates printer statis- NEB or the printer, as needed, monitors requests to write to 
tics such as pages per job or pages per day, the NEB having the log file, monitors application requests for device status, 
kept track of the number of jobs sent to the printer and the and maintains job statistics, as discussed above, 
date. At Step S12, the printer statistics are transferred to a 40 Briefly, the CPSOCKET program is a method of inter- 
non- volatile memory such as the printer's hard disk 114 or facing an interactive network board between the network 
NVRAM 111, or the NEB's NVRAM 228. Alternatively, and a peripheral device, comprising the steps of transferring 
Steps S10, Sll, S12 may be performed before Step S9, so a program from board ROM to board RAM for execution 
that statistics are stored every minute. from the RAM; and monitoring, with the program, a board 
Summarizing Steps S9 through S12, a method for logging 45 network interface to detect a network communication 
system statistics of a printer connected via a bi-directional directed to the peripheral device. The program then corn- 
interface to an interactive network board for LAN commu- mands the peripheral device to perform a function in 
nication includes the steps of counting in the printer the response to the network communication, and monitors a 
number of pages printed, and counting on the board the board bi-directional peripheral interface to detect and store 
number of jobs printed. The printer is interrogated daily over 50 status information of the peripheral device. Finally, the 
the bi-directional interface for the number of pages printed, program outputs the peripheral device status information 
and the board then calculates daily statistics using the onto the network through the network interface in response 
number of pages, the number of jobs, and other status to another network communication. 

information. The daily statistics are then stored and may be In FIG. 5B, Steps S15 and S17 indicate "run-time" layer 

accessed and remotely displayed using CPCONSOL from 55 functions, and Step S20 represents a "soft-time" application 

the network administrator's PC 14. An additional feature of layer. First, Step S15 determines whether data is being 

the "autologging" function is that different levels of statistics received over the LAN. When LAN data is received, the 

may be logged. For example, at a basic level, only the process proceeds to Step S16 and the software protocol type 

number of pages for each job may be logged. At more is determined (to be discussed in greater detail in section 4f 

advanced levels, the number of pages per job plus a log of 60 below). For example, the Ethernet data received over the 

failure conditions may be logged; or the job start and end LAN may be one of the following software protocols: e.g. 

times may be logged in addition to the failure conditions and NetWare® over SPX/IPX; UNIX over TCP/IP; or Mac 

the number of pages per job. The logging level is set by Systems 7 over AppleTalk. Basically, the software protocol 

CPINIT. type may be determined according to the frame packet type 

In FIG. 5B, at Step S13, the SAPSERVER program (to be 65 sensed in Step S7 above, 

discussed in greater detail in section 4g below) advertises If CPSOCKET determines that LAN data is not being 

the NEB as having both CPSERVER and CPSOCKET received in Step S15, Step S17 determines whether SCSI 
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data is being received, and if SCSI data is being received, it the attached printer is set to a default environment which 

is input from the printer in Step S18, and then stored in specifies, for example, default fonts, papers trays, collation, 

DRAM 220 in Step S19. stapling, etc., to insure that the next print job will be started 

After the storing of printer data in Step SI 9, or if SCSI with the printer in a known configuration (to be discussed in 

data is not being received in Step S17, the process proceeds 5 greater detail in section 4m below), 

to Step S20 where "soft -time" tasks are performed on a Step S25 may be thought of as guaranteeing a safe 

multi-tasking basis as controlled by a multi -tasking software environment for the printer by ensuring that the printer 

program called "MONITOR" (to be discussed in greater settings (e.g. portrait mode, duplex, etc.) are returned to 

detail in section 41 below). Step S20 is therefore a "back- between logical printing jobs. For example, while Novell 

ground" process which runs concurrently throughout the 10 NetWare® includes the ability to prefix every job with 

flowchart depicted in FIGS. 5 A, 5B and 5C. That is, when- printer escape sequences to reset the printer environment, 

ever "soft-time" tasks are being performed, the micropro- such escape sequences reside in a database on the network 

cessor 216 will ensure time-shared, parallel, non-preemptive file server, and the print job in question might not originate 

processing of the "soft-time" tasks. from that file server. In order to ensure a guaranteed safe 

More particularly, MONITOR is a software module 15 environment, the NEB will store the requisite configuration 

downloaded from EPROM 222 to DRAM 220 in Step S6. parameters, and will be responsible for resetting the printer 

MONITOR is a non-preemptive multi-tasking monitor environment between print jobs. 

which distributes the processor usage among the several In summary, a method for providing a default : cpnfigura- 

application tasks which are currently active. The non- tion to a'LjW^printer.having-an interactive-network board 

preemptive nature of the monitor requires that each appli- 20 roupled^lhereto ^md^es^th^ 

cation task periodically relinquish control so that other tasks cpnfiguration-over^a-tAN interface~ai~the interactive net^ 

gain the opportunity to execute. The relinquish control iwo?lTboard. >The default^^onfiguratidn "may be" stored in 

mechanism is implemented using a software interrupt to NVRAM 228 in the NEB or stored in an NVRAM or disk 

pass control to the MONITOR. At an interrupt, MONITOR in the printer over the bi-directional interface between the 

saves the state of the current task, restores the state of 25 board and the printer. Then, the default configuration is 

another active task, and resumes (or commences) execution downloaded from the NVRAM in the printer to the DRAM 

of the new task. The task which originally relinquished 220 on the board over the bi-directional interface. When the 

control eventually regains control at the interrupt point, i.e. board receives print information over the LAN interface and 

with its context restored to the same condition as when it provides the print information to the printer over the 

relinquished control. 30 bi-directional interface, the board detects an end of print job. 

In summary, Step S20 comprises the step of monitoring a In response to this detection, the default configuration is sent 
plurality of-appUcation" tasks ina-multi-taskkg-interactivej to the printer whereby the printer is set in its default 

•network board to distribute processor^resqurcesrA'memory configuration. 

store's"*" first application task which may queue a file server Additionally, a plurality of default configurations may be 

to get a network interface to obtain a queue of print files to 35 stored, and an appropriate default configuration may be 

be printed, and which channels the print files to a printer selected remotely from another LAN entity. For example, a 

coupled to the board through an interface. The memory also method of setting one of a plurality of default configurations 

stores a second application task which may receive remote may include a step of detecting, at the board, the origination 

status inquiries over a LAN interface, interrogate the printer of a print job and identifying the source of the job. 

over a bi-directional interface to obtain printer status and a 40 Subsequently, an appropriate default configuration is 

response to the received status inquiry, and provide the selected from among the stored configurations, and the 

status information over the LAN interface to the status selected default configuration is then sent to the printer at the 

requester. The first and second application tasks each include beginning or end of the print job. 

a relinquish command which causes the currently executing In FIG. 5C, if it is determined that a print job is not 

application task to periodically relinquish control to the 45 required at Step S21, Step S26 determines whether a status 

MONITOR. The MONITOR saves the state of the relin- request has been made over the LAN requesting the status of 

quishing task, restores the state of the non-relinquishing the attached printer. If it is determined that a status request 

task, and resumes execution of the non-relinquishing task. has been received, Step S27 determines the type of status 

In FIG. 5C, presuming that data has been received over request. For example, printer status such as error codes, the 

the LAN at Step S15, Step S21 determines whether the 50 number of pages printed, the toner status, etc., may be 

received data is for a print job or not. If it is for a print job, requested. 

microprocessor 216 acts as the LAN file server for an active At Step S28, the microprocessor 216 retrieves the 

print file and transfers print job blocks to DRAM 220 at Step requested status data from DRAM 220, assembles the status 

S22. data, and sends it to the LAN through the LAN interface (to 

At Step S23, microprocessor 216 assembles blocks of 55 be discussed in greater detail in section 4i below). Thus, in 

image data and control information, and sends the blocks to Step S28, more than simple "on/ofF* information may be 

the printer through the SCSI interface. In this step, the transmitted to the LAN so as to inform the LAN of the 

microprocessor 216 effectively adds "beginning of job"and detailed status of the printer. In a broad application, Step S28 

"end of job" indications to the data stream received over the encompasses the export of printer front panel status over the 

LAN. It does this by opening the XP (data) channel at the 60 LAN, and the import of front panel control commands from 

beginning of a print job, and by closing the XP channel at the the LAN. That is, the network administrator at the PC 14 

end of a print job. may request and receive a display indicating all of the printer 

At Step S24, the process waits until the print job is information included on the printer front panel display 116. 

complete. Once the print job is complete, Step S25 will The network administrator may then activate different 

unambiguously set the printer to a default environment. It is 65 printer front panel functions on his/her PC, and such func- 

also possible to set the default configuration before (or lions will be transmitted to the printer where the selected 

during) the print job. That is, the NEB itself will ensure that control will be effected. 
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In summary, at Step S28, a method for remotely control- tion of the module, a definition of the module's attributes, 

ling a manually-operable function of a networked printer and a pointer to a header for a succeeding module. The 

through an interactive network board having a LAN inter- binary image file is then constructed containing the specified 

face for LAN communication, comprises the step of issuing, modules and their associated headers. Finally, a module of 

at a remote location, a command to the board that will cause 5 ROM-resident code is appended to the binary image, the 

the board to transfer printer status information through the ROM-resident code receiving control at power-up, provid- 

board to the remote location through the LAN interface. At ing POST, loading at least some of the modules from the 

the remote location, a printer status may be displayed, and binary image file into DRAM 220, and providing basic 

a second command may be issued at the remote location to board I/O services. 

the board through the LAN interface to cause the board to 10 Before writing new data into EPROM 222, it is first 

perform a manually-operable function. necessary to unequivocally ensure that a write operation is, 

If the received LAN data is neither a print job nor a status in fact, intended. Obviously, any accidental writings into 

request, it is determined at Step S29 that the received data EPROM 222 could render the NEB unusable. Therefore, 

may be a download operation, i.e., a transfer of data into the before information may be "flashed" to EPROM 222, a 

NEB for updating the ROM or RAM applications, e.g. 15 specified sequence of events will occur in Step S33 in order 

download may be utilized for transient diagnostics to be run to access the EPROM (to be discussed in greater detail in 

on the NEB. section 4p below). In the present embodiment, unless two 

First, at Step S30, the data is downloaded from the LAN data bits are changed in two separate I/O locations, the +12 

to the DRAM 220 (to be discussed in greater detail in section Volts necessary to write to the EPROM will not be provided. 

4n below). That is, the download is a process by which data 20 Briefly, a method of ensuring that the EPROM is not 

may be loaded into a network node and then acted upon or accidentally written into comprises a method of performing 

executed. For example, anything from patch code, to manu- a flash operation on an EPROM resident on an interactive 

facturing test routines, to firmware updates for the EPROM network board having a processing unit and a memory, 

may be downloaded. Also, application modules may be including the step of sending an I/O write signal to the 

stored in the LAN file server and then downloaded to the 25 processing unit. Then, the processing unit generates a first 

NEB every morning. address in the memory to cause a first bit to be in a 

In summary, the downloading of data from LAN to predetermined state in response to the I/O signal. A power 

DRAM comprises a method for altering an operational mode unit is then caused to provide +12 Volts to a transistor in 

of an interactive network board having a LAN interface, response to the first bit being placed in the predetermined 

including the step of activating a LAN communication 30 state. Then, an I/O receive signal is sent to the processing 

program for execution from DRAM, the communication unit which generates a second address in the memory to 

program channelling print information on the LAN to a cause a second bit to be in a preselected state in response to 

peripheral printer. Executable instructions which correspond the I/O receive signal. Then, the transistor is turned on in 

to the altered operational mode are then downloaded into response to the second bit being placed in the preselected 

DRAM via the LAN interface. The board is then com- 35 state causing the +12 Volts to flow to a power terminal of the 

manded via the LAN interface to begin execution of the EPROM, allowing a write operation to take place, 

altered operational mode. Before the new ROM image is actually stored in EPROM 

At Step S31, it is determined whether the downloaded 222, at Step S34 the new ROM image must be check- 
information is destined for EPROM 222 or DRAM 220. If summed and verified with a checksum value sent after the 
the information is destined for EPROM, a ROM image is 40 ROM image is received. Prior to erasing EPROM 222, data 
assembled at Step S32 (to be discussed in greater detail in and modules to be preserved, such as the MAC address, 
section 4o below). For example, downloading of EPROM must be loaded into DRAM 220 within the new ROM 
firmware from a remote location provides unique flexibility. image. 

In particular, downloading of on-board test routines, and After determining that the ROM image is verified and 

changing EPROM configuration firmware can be performed 45 after preserving all required data into the new ROM image 

from a remote location after the board is installed in the stored in DRAM 220, it is necessary to clear and erase 

printer. EPROM 222 to ensure no corruption of data upon loading of 

Step S32 is the process which constructs the binary image the new ROM image. Accordingly, at Step S35, EPROM 

file which is to be programmed into the EPROM 222. The 222 may be erased a plurality of times before the new ROM 

data destined for the EPROM is first downloaded to DRAM 50 image is stored therein. 

220 where a utility reads a configuration file containing the After erasing EPROM 222 at Step S35, the new ROM 

names of the modules to be placed in the ROM image. Then, image is "flashed" into EPROM 222 in Step S36 (to be 

a complete binary image file is constructed containing all of discussed in greater detail in section 4q below), 

the specified modules. A header precedes each module in the In summary, Step S36 relates to a method for remotely 

image, the header identifying the module, describing its 55 altering programmable firmware on an interactive network 

attributes, and pointing to the succeeding header to aid in board having a LAN interface including the step of activat- 

locating the modules during loading. The last module loaded ing a LAN communication program for execution from 

in the EPROM is the EPROM -resident code. It is placed at DRAM on the board, the communication program channel- 

the end of the ROM image so that the power-up initialization ling print information on the LAN to a peripheral printer. A 

code resides at the address expected by the microprocessor 60 ROM firmware image is then downloaded to the DRAM on 

216. the board via the LAN interface. It is next confirmed that the 

In summary, Step S32 comprises a process for formatting ROM image has been downloaded to the target board, and 

a binary image file which contains executable code modules the integrity of the ROM image is confirmed. The board is 

for storage in the EPROM. First, a configuration file is read then commanded to electronically erase the EPROM, and 

which specifies the code modules which form the binary 65 then the EPROM is flashed with the new ROM image, 

image. Next, a header is formed for each module specified Additionally, a "flash complete" signal may be sent to the 

in the configuration file, the header including an identifica- LAN after the flash operation, if desired. 



03/01/2004, EAST Version: 1.4.1 



5,8: 

23 

After the information is flashed to the EPROM 222, the 
NEB is then re-booted from the new ROM firmware image 
in EPROM 222 at Step S37, and the process returns to Step 
SI. 

In FIG. 5C, if Step S31 determines that RAM information 
is being downloaded, such information is first assembled in 
DRAM 220 via Step S38. Subsequently, Step S39 executes 
the RAM program, and the process returns to Step S13 
wherein SAPSERVER advertises PSERVER and 
CPSOCKET entities. 

This discussion concludes the overview of the NEB 
structures and functions when the NEB is installed in 
LAN-networked printer. A more detailed description of the 
operation of various aspects of the NEB hardware and 
software will now be provided. 
4a. Power-on Sequence 

Immediately following power-on, NEB 2 executes a 
power-on self test (POST), following which the NEB loads 
operational software from EPROM 222 into DRAM 220 for 
execution. 

More specifically, immediately following power-on, 
microprocessor 216 accesses POST program modules 
located in EPROM 222. Microprocessor 216 executes POST 
directly from EPROM 222 to test the functionality of the 
microprocessor, integrity of the programs stored in EPROM 
222 (for example, via checksum verification), operability of 
DRAM 220 (for example, through read/write cycles), oper- 
ability of SCSI controller 224, data integrity of NVRAM 
228, and operation of control register 230. POST may also 
include a comparison of the MAC address stored in PROM 
232 with a MAC address downloaded into EPROM 222. 

POST further includes operational checks of network- 
related hardware. More specifically, POST may include 
operability checks for SRAM 214 (for example, through 
read/write cycles), as well as a check of network activity to 
verify operation of network controller 206. 

Operation of other hardware in NEB 2 may be determined 
directly through additional POST testing. In some cases, 
where it is not possible for microprocessor 216 to test 
operation of hardware directly, as in the case of connectors 
202, 203 and 204, proper operation of that hardware may be 
implied through result codes received from direct testing. 

Upon termination of POST, microprocessor 216 puts a 
checksum code onto serial port 218 and then enters a 
window of quiescent operation (for example, a one second 
window) during which microprocessor 216 can receive 
commands (e.g. for testing — see paragraph 5 below) via 
serial port 218, The POST checksum code may be obtained 
by a device coupled to serial port 218 to determine the 
outcome of POST. For example, a no error condition may be 
indicated by a POST checksum code of "OOOOh", while a 
POST checksum code indicating an error may be indicated 
by a non-zero hexadecimal value which indicates the area of 
failure. In the case of failure, microprocessor 216 may also 
illuminate LED 240 on NEB 2 to signal to a user that an 
error has been detected. Preferably, LED 240 is illuminated 
on power-up and is only turned off if POST is successful. 

Following successful completion of POST and in the 
event that no commands are received via serial port 218 
during the one second quiescent window of activity, micro- 
processor 216 begins to load software modules stored in 
EPROM 222 into DRAM 220. Microprocessor 216 does not 
execute those software modules directly from EPROM 222, 
but rather loads those modules into DRAM 220 for execu- 
tion from DRAM 220. By virtue of this arrangement, it is 
possible to select the specific modules that are retrieved 
from EPROM 222 for execution out of DRAM 220 so as to 
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permit flexible configuration of NEB 2 (see section 4d 
below). For example, in accordance with a configuration 
command stored in NVRAM 228, microprocessor 216 may 
retrieve selective modules from EPROM 222 for loading 

5 into DRAM 220 and for execution from the DRAM. 

FIG. 6 shows the sequence by which different modules are 
retrieved from EPROM 222 and loaded into DRAM 220. In 
Step S6001, microprocessor 216 loads the SCSI driver from 
EPROM 222 into DRAM 220. The SCSI driver provides for 
operational sequence and control over SCSI controller 224 
and permits interface with printer 4 so as to send printer 4 
print data and so as to send and receive control information 
to and from printer 4. 

In Step S6002, microprocessor 216 loads the link support 
layer, or "LSL", from EPROM 222 into DRAM 220, and in 

35 Step S6003 microprocessor 216 loads network driver soft- 
ware from EPROM 222 into DRAM 220, and thereupon 
microprocessor 216 begins to execute the link support layer 
and the network driver from DRAM 220. The link support 
layer and the network driver provide common access to 

20 LAN communications on LAN bus 6. More particularly, as 
shown in FIG. 7, all networked devices, including a device 
such as NEB 2, interface with LAN bus 6 via an electrical 
interface 301 such as the network controller 206 used on 
NEB 2. The electrical interface 301 is driven by network 

25 driver 302 which in turn receives LAN frame data from link 
support layer software 304. Both the link support layer 304 
and the network driver 302 are common to different kinds of 
network software. For example, as further shown in FIG. 7, 
network application programs, such as those provided in 

30 NetWare® software by Novell (as illustrated at Arrow A) 
interface with the link support layer and the network driver 
via an internetwork packet exchange program, or "IPX", 305 
and a sequenced packet exchange program, or "SPX", 306. 
On the other hand, network application programs from 

35 UNIX provided by AT&T (as illustrated at Arrow B) inter- 
face to the LSL through "IP" module 315 and "TCP" module 
316. 

In NEB 2, only one type of network application programs 
is normally executed at any one time (although multiproto- 

40 col operations are possible as discussed in section 4f below). 
Explanation here will be made for NetWare® network 
application programs although it is also possible for UNIX 
network application programs to be executed as well. 
In Step S6004, microprocessor 216 loads a PRESCAN 

45 program from EPROM 222 and stores it into DRAM 220, 
and thereupon begins executing the PRESCAN program 
from DRAM 220. PRESCAN software interfaces with the 
link support layer to determine the frame packet type being 
transmitted on LAN bus 6. More particularly, as described 

50 above, there are four different possible frame packet types 
on an Ethernet-type network LAN bus: Ethernet 802.3, 
Ethernet II, Ethernet 802.2, and Ethernet SNAP. As 
described more fully below in section 4e, the PRESCAN 
software module monitors network communications on 

55 LAN bus 6 to determine the frame packet type. The frame 
packet type, once determined by PRESCAN, is stored in a 
predetermined common location in DRAM 220 for use by 
other network communication modules in the NEB. After 
determining the frame packet type, PRESCAN signals 

60 microprocessor 216 that its tasks are completed and allows 
microprocessor 216 to overwrite the memory occupied by 
the PRESCAN program with another program module. 

In Step S6005 microprocessor 216 retrieves the IPX and 
SPX program modules from EPROM 222 and stores them in 

65 DRAM 220, and thereupon begins executing the IPX and 
SPX modules from DRAM 220. Both IPX and SPX use the 
frame packet type determined by the PRESCAN module. 
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In Step $6006 microprocessor 216 retrieves the CNETX 
program module from EPROM 222 and loads that module 
into DRAM 220 and thereupon begins execution from 
DRAM 220. CNETX provides localized DOS-like function- 
ality to the NEB. 

In Step S6007, microprocessor 216 loads the SAPS- 
ERVER program module from EPROM 222 into DRAM 
220 and begins executing the SAPSERVER module from 
DRAM 220. As described more fully below in section 4g, 
SAPSERVER is a program module which allows two net- 
work server entities, such as CPSOCKET and CPSERVER, 
to advertise simultaneously from the single network node 
assigned to the NEB board, even though conventional net- 
work application programs such as those provided by Net- 
Ware® only permit advertising of a single network server 
entity from each network node. 

In Step S6008 microprocessor 216 retrieves the non- 
preemptive multi-tasking MONITOR (see section 4 1 below) 
from EPROM 222 and stores it into DRAM 220 and begins 
executing the multi-tasking monitor from DRAM 220. 

In Step S6009 microprocessor 216 retrieves the 
CPSOCKET server software module from EPROM 222 and 
loads it into DRAM 220 and begins executing the 
CPSOCKET server from DRAM 220. As will be described 
more fully below in section 4j, CPSOCKET initiates a 
request to SAPSERVER to advertise on behalf of 25 
CPSOCKET, and SAPSERVER begins making SAP adver- 
tisements on LAN bus 6. 

In Step S6010 microprocessor 216 retrieves print appli- 
cation servers such as CPSERVER or CRPRINTER from 
EPROM 222 and loads the print application servers into 
DRAM 222. In the case of CPSERVER, microprocessor 216 
begins executing the loaded print application servers from 
DRAM 220 which in turn requests SAPSERVER to make 
SAP advertisements on behalf of the print server. As 
described more fully below in section 4g, SAPSERVER 
interleaves advertisements for the CPSOCKET server and 
for the print server thereby acting as a surrogate SAP entity 
for both the CPSOCKET server and the print server. 
4b. Interfacing A Peripheral With A Local Area Network 

According to the broad aspects of the present invention, 
a peripheral such as a printer is coupled to a LAN using an 
interactive network board having software programs embed- 
ded therein. Preferably, the connection between the printer 
and the NEB is an SCSI interface so that large amounts of 
print data and status data are carried bi-directionally 
between the NEB and the printer. EPROM 222 stores a 
plurality of software modules for operationally configuring 
the NEB in the PSERVER or RPRINTER or LPR functional 
configurations. The EPROM 222 also stores a number of 
status control software modules for exporting status infor- 
mation from the printer over the LAN, and for importing 
control information from the LAN to the printer. The 
EPROM-resident firmware is downloaded to the DRAM 220 
upon power-up (as discussed in section 4a above), whereby 
the MONITOR multi-tasking program executes soft-time 
tasks until run- time interrupts are received from either the 
LAN or SCSI interfaces. 

NVRAM 228 stores a configuration word which specifies 
which modules stored in EPROM 222 should be down- 
loaded into DRAM 220 in order to configure the NEB with 
either a PSERVER or RPRINTER functionality. The micro- 
processor 216 executes the programs from DRAM 220, 
allowing print jobs to be received from the LAN and sent to 
the printer for printing, and allowing printer status to be 
returned over the LAN in response to a status request. 

The particular details of the structure and functions for 
interfacing the peripheral to the local area network are set 



forth above with reference to FIGS. 4, 5A, 5B and 5C, and 
in the following sections. 

4c. The Bi-Directional Interface Between The Local Area 
Network And The Printer 

The provision of a bi-directional SCSI interface between 
the NEB 2 and the printer permits a large amount of status 
information to be extracted from the printer, while still 
providing the print data to the printer. Further, by utilizing 
the bi-directional SCSI interface, the printer can respond to 
control commands issued from a remote location over the 
LAN. For example, the network administrator may issue a 
control command from his/her PC 14 that requests a par- 
ticular print job be printed a plurality of times, with high 
image density, and then stapled. Such control commands are 
sent to the NEB 2 over the LAN 6, and the NEB 2 transmits 
these control commands to the printer through the SCSI bus 
102. At the same time, the actual print data is transferred 
from file server 30 to the NEB 2, where the print data is 
packaged in blocks and transferred to the printer over the 
SCSI bus 102. Preferably, the NEB 2 indicates the "start of 
print job" by opening the XP data channel to the printer. 
Likewise, the NEB 2 indicates "end of print job*' by closing 
the XP data channel to the printer. Therefore, the NEB 2 can 
provide such indications to the printer. 

The use of the bi-direclional SCSI interface on the NEB 
2 also permits other types of peripherals to be coupled to the 
LAN. For example, since the SCSI interface is capable of 
transmitting large quantities of data to the LAN from the 
peripheral, it is possible to couple the NEB to an image data 
30 generating device such as a scanner (e.g., where printer 4 is 
an Optical Character Recognition ("OCR") device) or a 
facsimile machine. Thus, data produced by the image gen- 
erating device may be transferred to the NEB over the SCSI 
interface, and then put on the LAN for storage or retrieval 
by any of the LAN entities. As with a printer, large quantities 
of detailed control/status information can also be provided 
to/from the image data generating device. 

The detailed structural and functional features of the 
bi-directional SCSI interface on the NEB are set forth above 
with reference to FIGS. 4, 5A, 5B and 5C, and in the 
following sections. 
4d. ROM Firmware Configuration 

As described earlier with respect to FIG. 5 A, Step S6 
downloads selected software programs from EPROM 222 to 
45 the DRAM 220 for execution (see also FIG. 6 and section 
4a). The EPROM 222 is delivered with firmware modules 
which permit the NEB 2 to be configured with either 
RPRINTER or PSERVER functionality. Therefore, the func- 
tionality of the NEB 2 will be determined by which of the 
50 stored programs are downloaded from EPROM 222 to 
DRAM 220 in accordance with the configuration code 
stored in NVRAM 228. 

The NEB 2 firmware is configured initially, and can be 
reconfigured subsequently by running CPINIT on the net- 
55 work administrator's PC 14 (see section 4h below). 
However, even in an unconfigured state, NEB 2 itself will 
always activate those software modules needed to perform 
basic communication with the LAN. Using CPINIT, the 
network manager can determine, remotely, the current con- 
60 figuration of the NEB, or he/she can change the configura- 
tion as desired. Since the configuration information is stored 
in EPROM on the NEB board, the configuration information 
is retained across power cycles. 
The process by which the software programs for a par- 
65 ticular configuration are downloaded from the EPROM 222 
to the DRAM 220 will be described below with respect to 
FIG. 8. 
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After the board has been powered up at Step SI, the 
process proceeds to Step S8001 where microprocessor 216 
accesses EPROM -resident code in the EPROM 222 to read 
a configuration code (typically a word) from NVRAM 228. 
The configuration code will specify modules which can 
provide the NEB with either a PSERVER or RPRINTER 
functionality. Although the present embodiment includes 
only RPRINTER or PSERVER functional configurations, 
other configurations may be utilized where, for instance, the 
NEB 2 is installed in a different LAN entity, such as a 
scanner or a facsimile machine. 

After reading the configuration code from NVRAM 228, 
the microprocessor, at Step S8002, forms a configuration 
mask whose bit pattern corresponds to the read configuration 
code. At Step S80G3, a loader module resident in EPROM 
222 compares the configuration mask to the plurality of 
firmware modules stored in the EPROM 222. 

In detail, in Step S8004, a process begins whereby the 
EPROM -resident software modules are selected in bit- wise 
correspondence to the binary digits of the configuration code 
read from NVRAM 228. If it is determined in Step S8004 
that the currently-examined bit of the bit pattern matches a 
stored module, then that module is selected (at Step S8005) 
for downloading to DRAM 220, and the process skips to the 
next bit at Step S8006. Likewise, if Step S8004 determines 
that a bit of the bit pattern does not match the stored module, 
the process skips to the next bit at Step S8006. 

At Step S8007, it is determined whether the bit tested in 
Step S8004 is the last bit of the configuration mask bit 
pattern. If the tested bit is not the last bit, the process loops 
back to Step S8004, where the next bit of the bit pattern is 
tested with respect to the next stored module. When the last 
bit of the configuration mask bit pattern has been tested, the 
selected software modules are downloaded from EPROM 
222 to DRAM 220 at Step S8008. 

In the present embodiment, the software modules are 
loaded in the following sequence: SCSI Driver; Link Sup- 
port Layer; Network Driver; Prescan; IPX/SPX; CNETX; 
SAPSERVER; MONITOR; CPSOCKET; and Print Appli- 
cations (e.g CPSERVER, CRPRINTER) (see FIG. 6). 

After all of the software modules which correspond to the 
configuration codes stored in NVRAM 228 have been 
downloaded to DRAM 220, the loader function will pass 
program execution control to the MONITOR multi-tasking 
program at Step S8009. 

As discussed earlier, the configuration code stored in 
NVRAM 228 may be remotely altered using CP I NIT. This 
provides greater flexibility for making minor modifications 
to CPSERVER or CRPRINTER, or where entirely new 
configurations are desired to be set. Therefore, at Step 
S8010, a new configuration is received over LAN 6, and is 
loaded into NVRAM 228 at Step S8011. Preferably, the old 
configuration code will be erased or overwritten with the 
new configuration code. Then, the NEB re-boots itself and 
returns to Step SI. 

4e. Determining Frame Packet Type Using PRESCAN 

On any local area network, data is transmitted between 
network devices in packets or frames. But even in the 
context of a common network architecture, such as Ethernet, 
more than one format for the frame may be supported. Thus, 
even though it is known that Ethernet architecture is being 
used, it is not possible to determine the arrangement of data 
within each physical frame or packet of information on the 
Ethernet bus. In particular, as described above, Ethernet 
supports four arrangements of data, or formats, as follows: 
Ethernet 802.3, Ethernet II, Ethernet 802.2, and Ethernet 
SNAP. 
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In conventional network devices, which provide for a 
manually selectable operator interface, it is possible to 
advise the network device of the particular frame type being 
used on the Ethernet network. In the context of NEB 2, for 
which operator access is provided only via the network 
interface (or via the serial port 218 in a test configuration), 
it is not possible to set the frame packet type without first 
allowing operator access to the local area network which, of 
course, requires knowledge of the frame packet type. 

The PRESCAN software module allows NEB 2 to auto- 
matically determine the frame packet type currently being 
used for LAN communication on the LAN bus by monitor- 
ing broadcast communications on the LAN bus until the 
proper frame packet type is recognized. PRESCAN makes 
this determination based on recognizable components that 
are common to all four frame packet types used on Ethernet. 

In more detail, FIG. 9 shows the physical construction of 
different frame packets used on Ethernet. As shown in FIG. 
9, a physical frame 411 being transmitted on the LAN bus 
includes a 6-byte section 412 for storing the destination 
MAC address, and a 6-byte section 413 for storing the 
source MAC address. These 12 bytes comprise the first 12 
bytes of LAN data packets regardless of the frame type 
being used for LAN communication. A data section 414 
follows these 12 bytes. The data section is comprised of a 
variable number of bytes which are not used for the same 
purposes by the different frame packet types and which do 
not have the same number of bytes for the different frame 
packet types. 

Following the indeterminate area 414, the LAN commu- 
nication packet includes an IPX header 415 the first two 
bytes of which always has the value "FFFF" (hexadecimal). 
The remainder of the packet 416 follows the IPX header and 
comprises the data and other commands which characterize 
each different type of LAN communication packet. 

PRESCAN operates by monitoring the LAN communi- 
cation in accordance with each of the different packet types 
until the common area (such as IPX header 415) is recog- 
nized in one of those packet types. PRESCAN then stores 
40 that packet type for use by other network communication 
programs. 

FIG. 10 is a detailed flowchart for showing operation of 
the PRESCAN module. In Step S1001, microprocessor 216 
retrieves the PRESCAN module from EPROM 222 and 
45 loads it into DRAM 220 and thereupon begins execution of 
the PRESCAN module. The PRESCAN module is executed 
before the SPX and IPX modules, even if microprocessor 
216 retrieves those latter modules from EPROM 222 and 
loads them into DRAM 220 before the operational sequence 
50 shown in FIG. 10 is complete. More particularly, proper 
operation of the SPX and IPX program modules depends 
upon the identification of the frame packet type by PRES- 
CAN and therefore execution of SPX and IPX is deferred 
until after PRESCAN determines the proper frame packet 
type. 

In Step S1002, PRESCAN simultaneously binds through 
LSL to all four frame packet types, namely, Ethernet 802.3, 
Ethernet II, Ethernet 802.2, and Ethernet SNAP. That is, 
PRESCAN configures LSL such that for each packet of 
LAN communication, LSL provides a data group corre- 
sponding to each of the four frame packet types. Thereafter, 
PRESCAN goes inactive pending reactivation by an inter- 
rupt from the network driver. 

In Step S1003, the network driver monitors communica- 
tions on the LAN bus for broadcast traffic. Broadcast traffic 
means that the destination MAC address 412 is unspecified 
or is given a global specification of "FFFFFFFFFFFF" 
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(hexadecimal). The network driver continues to monitor UNIX multiprotocol environment, but it is to be understood 

communications on the LAN bus for broadcast traffic (Step that other operating protocols may be substituted for or used 

S1004) until broadcast traffic is received, whereupon flow in combination with those shown in FIG. 11. In FIG. 11, 

advances to Step S1005. In Step S1005, the MAC address NEB 2 is interfaced to LAN bus 6 via electrical interface 

fields 412 and 413 are stripped off the received data packet 5 321, network driver 322, and link support layer ("LSL") 

and the remainder of the data packet is provided to LSL. In 324, much as illustrated above in FIG. 7. Novell-specific 

Step S1006, LSL interprets the frame packet in accordance operating protocols are indicated at reference numerals 325, 

with each of the frame packet types and provides a data 326 and 327. More specifically, 325 and 326 are an SPX/IPX 

group in correspondence to each of the frame packet types. operating protocol stack (or tower) by which Novell- 

In Step S1007, the network driver reactivates PRESCAN 30 compatible applications programs communicate with the 

which determines which data group provided by LSL has the LAN bus through LSL. Novell-compatible applications 

proper first two bytes, of an IPX header, namely "FFFF" programs, including a Novell-compatible server such as 

(hexadecimal). That is, because of the variable data area 414 CPSERVER, are illustrated at 327. The Novell-compatible 

(variable data area 414 corresponding to each of the different software drives printer 4 via bi-directional SCSI bus 102 as 

packet types (FIG. 9)), LSL will properly identify the IPX is described above. 

header 415 in accordance with only one of the frame packet UNIX-compatible operating protocols are illustrated at 
types. In Step S1007, PRESCAN searches for the IPX reference numerals 335, 336 and 337. More specifically, 335 
header and, in accordance with which of the four data groups and 336 comprise a TCP/IP operating protocol stack (or 
is provided by LSL, it is able to determine a frame packet tower) by which UNIX-compatible application programs 
type that is currently being used on the LAN bus. 20 communicate to LAN bus 6 via LSL. UNIX-compatible 
In Step S1008 PRESCAN stores the corresponding frame network application programs, including a UNIX- 
packet type in a common area in DRAM 220 so that the compatible printer server such as CLPR, are designated at 
frame packet type can be used by other network application 337. The print server CLPR drives printer 4 via SCSI bus 
programs such as SPX and IPX, Thereafter, in Step S1009, 102 as described above. 

PRESCAN frees its storage area in DRAM 220 so that 25 Prescan module 339 interfaces with LSL 324 to determine 

microprocessor 216 may overwrite that data area with other the frame packet type being transmitted on LAN bus 6 for 

software modules, if desired. each of the operating systems. In more detail, each operating 

4f. Multiprotocol Operation system such as the UNIX operating system and the Novell 

In a multiprotocol operation, two different operating sys- operating system can communicate on LAN bus 6 in a 

terns carry on LAN communications over a single local area 30 variety of frame packet types. When LAN bus 6 is an 

network bus, but using respectively different operating pro- Ethernet type LAN bus, then a UNIX operating system can 

tocols. For example, a Novell-compatible operating system communicate over the Ethernet by any of three frame packet 

communicates over a LAN bus using SPX/IPX operating types, namely, Ethernet 802.2, Ethernet II and Ethernet 

protocol, while a UNIX-compatible operating system com- SNAP. Likewise, when LAN bus 6 is an Ethernet-type bus, 

municates over the LAN bus using a TCP/IP operating 35 then a Novell operating system can communicate over the 

protocol. Other operating systems, such as the AppleTalk® LAN bus by any of four frame packet types, namely, 

operating system provided by Apple Corporation, use Ethernet 802,2, Ethernet 802.3, Ethernet II and Ethernet 

respectively different operating protocols for LAN commu- SNAP. It is possible for both the Novell operating system 

nication over a single network bus in a multiprotocol net- and the UNIX operating system to use the same frame 

work environment. 40 packet type; it is the operating system protocols (SPX/IPX 

Ordinarily, NEB 2 is configured to communicate to a for Novell and TCP/IP for UNIX) which determine which 
single network operating system, but it may also be config- one of the operating systems in a multiprotocol environment 
ured to operate in a multiprotocol network environment, for is currently communicating on the LAN bus. 
example, a combined Novell/UNIX multiprotocol environ- In the multiprotocol environment illustrated in FIG. 11, 
ment. In this configuration, NEB 2 includes a Novell- 45 PRESCAN module 339 determines the frame packet type 
compatible peripheral server, such as the aforementioned being used by each operating system by repeating the steps 
CPSERVER, which checks job queues in a file server on a shown in FIG. 10 for each of the operating system protocols 
Novell operating system, as well as a UNIX-compatible (see section 4e above). For example, when Novell- 
peripheral server, such as the aforementioned CLPR compatible and UNIX-compatible systems comprise the 
(Custom Line Printer Remote), which, in coordination with 50 multiprotocol environment, then PRESCAN simultaneously 
checks made by CPSERVER, also checks for job queues in binds through LSL to all four frame packet types for an 
a file server for a UNIX operating system. Both servers, here SPX/IPX protocol tower, so as to determine the frame packet 
CPSERVER and CLPR, service common peripheral type in accordance with the data group returned from LSL 
resources, here a single peripheral such as a printer, and to which has the proper IPX header. Then, PRESCAN binds 
avoid contention for control of the common resources, both 55 simultaneously through LSL through all three frame packet 
servers are able to seize control of the peripheral to the types having a TCP/IP protocol tower. PRESCAN deter- 
exclusion of other servers, to signal other servers that control mines the frame packet type being used by the UNIX- 
has been seized, and to relinquish control of the peripheral compatible operating system in accordance with the data 
when the job queue has been emptied. It is also possible for group having the proper TCP/IP header, 
each server to check with other servers to determine if other 60 In more detail, to adaptively and automatically determine 
servers have a pending request for use of the peripheral. In which of plural predetermined frame packet types is cur- 
the case where there is a pending request, the server can rently being used for LAN communication in a multiproto- 
relinquish control of the peripheral at the end of a current job col network environment, the PRESCAN program module 
even though there are jobs remaining in the job queue, so as 339 is downloaded from EPROM 222 into DRAM 220 
to allow alternating use of the peripheral by each server. 65 where microprocessor 216 executes the PRESCAN module. 

FIG. U illustrates NEB 2 configured for multiprotocol To determine the frame packet type for the first operating 

network operations. FIG. 11 illustrates a combined Novell/ system, PRESCAN first configures LSL to bind simulta- 
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neously to a plurality of frame packet types corresponding to 
a first operating system protocol, such as SPX/IPX operating 
protocol for Novell-compatible operating systems. Network 
driver 322 monitors the LAN communication bus to capture 
broadcast traffic for the first operating system. In response to 
capturing such broadcast traffic, LSL provides plural data 
groups for the captured broadcast traffic, each of the data 
groups corresponding to a different one of the plural packet 
types. The PRESCAN module 339 is reactivated to prescan 
each data group for the presence of a predetermined header, 
such as the SPX/IPX header, and stores the frame packet 
type corresponding to the data group having the predeter- 
mined header for use by the first operating protocol tower. 

To determine the frame packet type being used for the 
second operating system such as a UNIX operating system, 
PRESCAN configures LSL to bind simultaneously to a 
plurality of frame packet types corresponding to the second 
operating system protocol, such as TCP/IP for a UNIX 
operating system. The network driver monitors the LAN 
communication bus to capture broadcast traffic for the 
second operating system, and provides plural data groups 
corresponding to the captured broadcast traffic, each of the 
data groups corresponding to a different one of the packet 
types. The PRESCAN module prescans each data group for 
the presence of a predetermined header, such as the TCP/IP 
header for UNIX, and stores the frame packet type corre- 
sponding to the data group having the predetermined header. 

Once knowledge of the frame packet types being used by 
each of the operating systems in the multiprotocol environ- 
ment has been obtained, the Novell -compatible network 
application programs 327, such as CPSERVER, and the 
UNIX-compatible network application programs 337, such 
as CLPR, can both communicate on the LAN bus 6. The two 
application programs 327 and 337 also communicate with 
each other as illustrated schematically by signalling line 
340. Using signalling line 340, which may be implemented 
as a control register stored in DRAM which is commonly 
accessed by programs 327 and 337, programs 327 and 337 
can communicate with each other so as to signal that one of 
them has seized exclusive control over printer 4 or to signal 
that one of them has a pending request for use of printer 4, 
as will be described more fully hereinbelow. 

In operation, a first server such as CPSERVER, checks its 
operating system job queue, and if there is print information 
in the job queue, receives the print information from its 
operating system. In coordination with job queue checks by 
the first server, the second server such as CLPR checks its 
operating system job queue and, if there is print information 
in the job queue, receives job information from the operating 
system. When one of the servers has acquired sufficient 
information to require use of the printer peripheral, it seizes 
exclusive control of the printer, and signals to other servers 
via signalling line 340 that it has exclusive control of the 
printer. This prevents contention problems whereby other 
servers may inadvertently try to insert print jobs into printer 
4. 

The first server retains exclusive control over printer 4 
until its job queue has been emptied. When its job queue has 
been emptied, the first server relinquishes control of printer 
4 after which it may be used by any of the other servers. 

Alternatively, even though the first server's job queue 
might not yet be empty, when the first server reaches the end 
of a print job, the first server may interrogate other servers 
via the signalling line 340 to determine if the other servers 
have requests pending for the use of printer 4. If other 
servers have requests pending, then the first server may 
temporarily relinquish control of the printer so as to permit 
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alternating use of the peripheral by each of the servers. In 
this case, when the first server relinquishes control over the 
printer, it also signals that it has a pending request for use of 
the printer. 

5 4g. Advertising Multiple Servers From A Single Network 
Node Using SAPSERVER 

As mentioned above, NetWare® only allows a single 
network server from each non-fileserver network node to 
advertise its services on the LAN bus. However, in the 

10 multi-tasking environment established by the non- 
preemptive MONITOR, NEB 2 provides more than one 
network server. In particular, NEB 2 provides the services of 
the print server (CPSERVER, CRPRINTER or CLPR) as 
well as the services of the socket server (CPSOCKET). The 

15 SAPSERVER program module allows both network servers 
to advertise their services from a single network node, here 
the NEB, in a LAN communication system which normally 
supports advertising of only a single network server from 
each node. SAPSERVER accomplishes this by acting as a 

20 surrogate server (or SAP'ing entity) from the NEB which 
interleavedly advertises the services of each of its client 
servers, here CPSOCKET and CPSERVER. 

SAPSERVER listens to the network for SAP broadcast 
requests directed to one of its clients and responds with the 

25 server type of its client, the server name, and a communi- 
cation socket number by which the client can establish direct 
LAN communication. 

FIG. 12 is a view for explaining the software structure of 
SAPSERVER, and FIG. 13 is a flow diagram for explaining 

30 operation of SAPSERVER. 

As shown in FIG. 12, SAPSERVER is positioned in the 
software hierarchy at the application level of software so 
that it can communicate directly with the SPX and IPX 
network levels of software. SAPSERVER acts as a surrogate 

35 SAP'ing entity for each of its clients which in the case of 
NEB 2 consists of the socket server program CPSOCKET 
and the print server program CPSERVER as designated by 
the configuration of the board. SAPSERVER may also be 
configured to serve other clients as well, as illustrated 

40 diagram matically at "CLIENT N". 

As shown in FIG. 13, after microprocessor 216 retrieves 
the SAPSERVER program module from EPROM 222 and 
stores it in DRAM 220, microprocessor 216 commences 
operation of the SAPSERVER program and configures it to 

45 listen for SAP proprietary broadcasts to the SAP proprietary 
socket (Step S1301). In Step S1302, after microprocessor 
216 retrieves the CPSOCKET module from EPROM 222 
and stores it for execution in DRAM 220, the CPSOCKET 
program module issues a request to SAPSERVER to adver- 

50 tise CPSOCKET services. In accordance with standard SAP 
protocol, SAPSERVER commences periodic advertisements 
for CPSOCKET (Step S1303), for example, at one minute 
intervals. 

In Step S1304, after microprocessor 216 retrieves the 
55 CPSERVER module from EPROM 222 and stores it for 
execution from DRAM 220, CPSERVER issues a request to 
SAPSERVER for SAPSERVER to advertise CPSERVER 
services over the network. SAPSERVER commences peri- 
odic SAP advertisements for the services of CPSERVER and 
60 also continues to advertise the services for CPSOCKET. As 
shown in Step S1305, the advertisements are interleaved. 

Step S1306 determines whether a broadcast request has 
been received at the SAP proprietary socket (e.g. socket 
number 453). Until a broadcast request has been received at 
65 the proprietary socket, SAPSERVER simply continues to 
interleavedly advertise for the services of CPSERVER and 
CPSOCKET. However, when a broadcast request is received 
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at the proprietary socket then in Step S1307 SAPSERVER 
determines whether the broadcast request is for the services 
of one of its clients, here for the services of CPSOCKET or 
CPSERVER. If the broadcast request is not for one of 
SAPSERVER 's clients, then flow simply returns to Step 5 
S1305 where SAPSERVER continues to interleavedly 
advertise for its clients. On the other hand, if the broadcast 
request is for one of SAPSERVER' s clients, then flow 
advances to Step S1308. 

In Step S1308, SAPSERVER responds with an IPX 10 
packet on the proprietary socket number 453. The IPX 
packet contains the server type of its client, the server name, 
and a communication socket number. The IPX packet also 
designates a communication socket over which the broad- 
cast requestor can establish direct communication with the 15 
client. Thereupon, SAPSERVER returns to Step S1305 so as 
to continue to interleavedly advertise for each of its clients. 

In Step S1309, the broadcast requester establishes direct 
SPX connection with the client designated in the broadcast 
request over the communication socket designated in Step 20 
S1308. In the present configuration, where services of the 
print server CPSERVER is requested, the socket number is 
8060. On the other hand, when requests for services of the 
CPSOCKET server is requested, the socket number is 83B4 
for communication and 83B5 for connection. Direct com- 25 
munication then proceeds as described more fully herein- 
below. 

4h. Configuring The Networked Printer Using CPINTT 

FIG. 14 is a flow diagram showing how a network 
administrator can use CPINIT from PC 14 to initialize and 30 
to configure, and later to reconfigure, both NEB 2 and printer 
4 in which the NEB resides. 

In Step S1401, the CPINIT utility uses a service adver- 
tising protocol (SAP) on the network to determine which 
networked printer devices are available to respond to 35 
CPINIT inquiries. At each of the NEB boards, CPSOCKET 
responds with server type, server name and a unique socket 
number by which each NEB can be accessed directly, and an 
indication of whether or not the NEB requires configuration. 

In Step S1402, CPINIT constructs a list of all NEB's and 40 
their associated devices, and presents them in a menu form 
so that they can be selected by the system administrator. 
Following selection, CPINIT requests the current configu- 
ration of the targeted NEB (Step S14Q3). More specifically, 
CPINIT sends a request to the targeted NEB via the LAN 45 
interface. At the NEB, CPSOCKET, receives the request for 
configuration information from the LAN interface. 
CPSOCKET collects the needed configuration information, 
and directs it via the LAN interface to CPINIT at the system 
administrator's PC 14 (Step S1404). In Step S1405, CPINIT 50 
displays a menu of the current configuration of the targeted 
NEB. 

In Steps S1406 through S1408, the system administrator 
specifies a desired configuration for the targeted board. More 
particularly, configuration is specified on the system admin- 55 
istrator's PC 14 by means of a user interface such as a menu 
display. The following configuration parameters are selected 
by the operator to set the configuration information: (1) 
logging information (Step S1406), (2) NEB name (Step 

51407) , and (3) application type (such as CPSERVER) (Step 60 

51408) . 

Under logging information, the system administrator 
specifies one of four different levels of logging: "NONE", in 
which logging is disabled; "AUTO", in which basic printer 
usage statistics are logged once per day; "ERROR", in 65 
which basic printer usage statistics and error events are 
logged as they occur; and "JOB", in which basic usage 
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printer statistics, error events and job start/end information 
are all logged as they occur. After selecting the log 
preference, the system administrator must also set the maxi- 
mum log size (except when "NONE" is selected) so as to 
permit the printer to reserve this amount of space on its disk 
(or on its NVRAM HI in the event there is no printer disk 
or in NVRAM 228 in the NEB) for storing log information. 

Under NEB name information (Step S1407), the system 
administrator may assign an alphanumeric name to the NEB, 
such as a descriptive name like "2nd Floor Laser". The 
descriptive name is stored by the NEB in its NVRAM and 
is used by the NEB and other network devices to assist in 
identification. 

Under application type selection (Step S1408), the system 
administrator selects whether to configure the NEB as a 
CPSERVER or a CRPRINTER. If CPSERVER is selected, 
it is necessary to designate the name of the print server 
assigned to the NEB, password, application buffer size, 
queue service mode, form numbers, the printer number of 
the printer in which the NEB resides, the name(s) of the print 
queue(s) serviced by the NEB, and the name of the primary 
file server. If CRPRINTER is selected, it is necessary for the 
system administrator to designate the name of the print 
server through which the NEB obtains its print information, 
the printer number of the printer in which the NEB resides, 
the name(s) of the print queue(s) serviced by the NEB, and 
the name of the primary file server. 

In Step S1409, CPINIT sends the new configuration to the 
NEB via the network LAN. At the targeted NEB, 
CPSOCKET receives the new configuration information and 
stores it in NVRAM 228 (Step S1410). 

To complete the configuration of the NEB, the NEB 
should be re-booted. The system administrator issues a 
command via CPINIT which in turn sends a command to 
re-boot via the LAN to the targeted NEB (Step S1411). At 
the NEB, CPSOCKET receives the command to re-boot, and 
re-boots the NEB in the new configuration (Step S1412). 
4i. Accessing The Networked Printer Using CPCONSOL 

CPCONSOL is a utility program executed from the sys- 
tem administrator's PC 14 by which the NEB can be used for 
maximum control and efficiency of the networked printer. 
Using CPCONSOL, it is possible to remotely track routine 
and ongoing maintenance parameters. For example, it can be 
determined if toner is low, if the paper tray is empty, if a 
page is jammed, or if the printer is not responding at all. 
CPCONSOL can also keep track of the total number of 
pages printed to schedule routine and preventative 
maintenance, as well as plan for eventual printer replace- 
ment. 

The CPCONSOL utility gives the system administrator 
access to statistics about the printer operation as well as the 
efficiency of network communications. CPCONSOL can 
determine the total number of pages printed, as well as the 
average page-per-minule rate, average pages-per-day, and 
other statistics that allow monitoring of the operating effi- 
ciency of the printer. 

The network statistics allow gauging the efficiency of 
communications on the network, frequency of transmit and 
receive errors as well as retries, overrun, and underrun 
errors. 

When multiple printers are installed, CPCONSOL can 
remotely keep track of each printer's usage, both in terms of 
total jobs as well as total pages. This allows job tracking 
such as for direct departmental billing for items such as 
consumable paper costs. 

By ongoing monitoring CPCONSOL can help determine 
whether to relocate or add network printers for better effi- 
ciency as well as forecast the need for replacement. 
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CPCONSOL can also set up default (safe) environment 
parameters which ensure that the printer is configured the 
same way prior to each print job (see section 4m below). The 
user, of course, can modify that configuration within the 
print job itself. 

FIG. 15 is a detailed flow chart showing operation of 
CPCONSOL. Like CPINIT, CPCONSOL first broadcasts on 
the LAN to request identification of all NEB devices 
attached to the LAN (Step S1501). At the NEB's, 
CPSOCKET responds with the unique network ID*s and the 
communication socket numbers assigned to the NEB (Step 
S1502). CPCONSOL collects this response information for 
all NEB's and displays a list of responding NEB's to the 
administrator (Step S1503). The administrator selects one of 
the NEB's whereupon CPCONSOL establishes direct net- 
work communication with the selected NEB by means of 
LAN broadcasts to the network ID and socket numbers. 

Once direct LAN communication is established with the 
target NEB, CPCONSOL operates by means of a user 
interface such as a menu display (Step S1504). The menu 
divides the functions of CPCONSOL into five groups: 
Environment, Network, Logging, Application Control, and 
Printer Status. These functional groups are detailed in the 
following sections. 
[Environment Group (Step S1505)] 

The environment selection allows CPCONSOL to display 
the current environment of the selected printer (Step S1506), 
and to modify and store the new environment (Step S1507). 
The environment is subdivided into four groups: Common 
Environment, Interface, Control, and Quality. 

Upon selecting Common Environment, CPCONSOL will 
initiate a LAN request to the target NEB for the settings for 
Emulation Mode, Feeder, and Total Page Count. 
CPSOCKET at the target NEB will receive the LAN request, 
obtain the desired information from its attached printer via 
the bi-directional SCSI interface, and send the information 
to CPCONSOL at the administrator's PC 14 via the LAN 
interface. There, CPCONSOL displays a listing showing the 
emulation mode, the feeder, and the total page count 
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TABLE 3-continued 
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Control Information 


Description 




upper left corner of the 




page in millimeters. 


Error Skip 


Displays whether the 




rirint#*r m c^t fnr 

UJJJJLvl oCL LXJl 




automatic or manual error 




skipping. 


Buzzer 


On or Off setting of the 




printer buzzer. 


Toner Low 


If the toner low, a WARNING 




is displayed. 


28- Error 


Detection of Memory Full 




error can be turned on or 




off. 


Paper 


Paper sizes that arc 




available in the printer. 


Current Paper 


Paper cassette that is 




currently selected in the 




printer. 



Upon selecting the Quality group, CPCONSOL, after 
requesting and receiving information from the targeted NEB 
via the LAN interface, displays the settings for Selection 
Mode, Refine, Memory Usage and Low Resolution mode. 

25 [Network Group (Step S1508)] 

The network selection allows CPCONSOL to display the 
compiled statistics about the networked printer performance 
on the network (Step S1509), and to modify and store the 
new network group (Step S1510). These are subdivided into 

30 media-dependent and media-independent related transmit 
and receive statistics. CPCONSOL can also clear all statis- 
tics. 

When the system administrator selects the Network 
group, CPCONSOL initiates a network request via the LAN 
interface to the targeted NEB. At the NEB, CPSOCKET, 
responds to the request and obtains the needed performance 
information. The information is collected by CPSOCKET 
and returned to CPCONSOL at the administrator's PC 14 via 
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the LAN interface. At the administrator's PC 14, CPCON- 
Upon selecting the Interface menu CPCONSOL will 40 SOL displays the media-dependent and media-independent 

" transmit and receive information. 

Media-dependent receive and transmit statistics are sum- 
marized in Tables 4 and 5. 



initiate a LAN request to the targeted NEB for interface 
information. When the NEB responds, CPCONSOL causes 
the interface listing to display the interface that is currently 
set for the selected printer. 

Selecting the Control menu likewise causes CPCONSOL 45 
to initiate a LAN request to the targeted NEB which in turn 
interrogates its printer via the bi-directional SCSI bus for 
printer settings. The printer settings are returned to CPCON- 
SOL over the LAN interface which displays the current 
settings of the printer in accordance with Table 3. 

TABLE 3 



TABLE 4 



Media-Dependent 
Receive Statistic 



Description 



50 



Control Information 



Description 



Contrast 
Timeout 



Message 
Copy 
Offset X 



Offset Y 



Printer contrast setting. 
This is the setting of the 
job time-out set in the 
printer. 

Language in which messages 
are displayed. 
Number of copies of each 
page to be printed. 
The offset, if any, in the 
horizontal direction from 
the upper left comer of 
the page, in millimeters. 
The offset, if any, in the 
vertical direction from the 



CRC 



Missed Frames 



Align Errors 



Received Disabled 



60 



65 



Deferring 



Overflow 



Overruns 



Total number of Cyclic 
Redundancy Check errors 
detected by the LBP-Remote 
Number of packets missed due 
to lack of space in the 
receive buffer, or the 
controller is in the monitor 
mode. 

Indicates that the incoming 
packet did not end on a byte 
boundary. 

Controller was in the 
monitor mode. 
Set when internal Carrier 
Sense or Collision signals 
are generated in the 
encoder/decoder. 
Buffer ran out of space 
while data was being 
received from the network. 
The buffer did not respond 
fast enough to keep data 
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TABLE 4-continued 



Media- Dependent 




Receive Statistic 


Description 




from flowing from the 




network. 


TABLE 5 


Media- Dependent 




Transmit Statistic 


Description 


Collisions 


Packet Collision Total 


Heartbeat 


Number of failures of the 




transceiver to transmit a 




collision signal after 




transmission of a packet 




with this bit set. 


Out of Window Call 


Set for the number of 




collisions that occurred 




after slot time. 


Underruns 


The buffer did not respond 




fast enough to keep data 




from flowing to the network. 



15 



20 



Media independent statistics display the network statistics 
that aren't related to the transmission media. Such statistics 
are a good summary of overall printer activity on the 
network, and are summarized Table 6. 



TABLE 6 



Media Independent Parameter Description 



Abort Rx Frame 


General receive problems. 


Total Rx Frame 


Total number of received 




frames. 


Rx Too Big 


Receive frame larger than 


expected. 


Rx Too Small 


Receive frame smaller than 




expected. 


Abort Tx Frame 


General transmit problems. 


Total Tx Frame 


Total number of transmitted 




frames. 
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power-on for a printer without a disk drive. Average is the 
cumulative totals divided by the number of days since the 
last reset. For each of the three categories, the NEB main- 
tains totals for the following values (unless CPINIT has set 

5 the logging level to "NONE"): days (number of days since 
a reset was issued or since power-on), pages printed, print 
jobs processed, off-line time, and printing time. 

CPCONSOL also retrieves the stored log file to the screen 
for viewing and printing. The log file is in reverse chrono- 

10 logical order and includes the following record types. The 
precise content of the log file varies in accordance with the 
logging level set by CPINIT, as summarized in Table 7. 



TABLE 7 


Type 


Data 


Description 


STD 


<Days><Pages><Jobs><Offlme><Printing> 


daily 






statistics 


STC 


<Days><Pages><Jobs><OBIine><Pruiting> 


cumulative 






statistics 


STA 


<DaysxPagcs><Jobs»Offline><Printing> 


average 






statistics 


SOJ 


<ApplicationxUser><JobxFile serve r> 


start of 




<QueuexForm> 


job 


INI 


<NEB TypexROM/MAC AddressxPrinter 


Initializa- 




Name> 


tion record 


POW 


<NEB TypexROM/MAC AddressxPrinter 


power on 




Name> 


record 


RBT 


<NEB TypexROM/MAC AddressxPrinter 


reboot 




Name> 


record 


WAR 


<Appl ication xWa rn ing> 


warning 


EOJ 


<ApplicationxUserxJobxDisposition> 


end of job 


ERR 


<Appl ication ><Error> 


error 



[Logging Group (Step S1511)] 

The logging group selection allows CPCONSOL to dis- 
play the set of job-related statistics that the NEB compiles 45 
(Step S1512), and to modify and store the new logging 
group (Step S1573). The displayed data include job 
averages, page averages, and performance data. CPCON- 
SOL can reset the totals to zero with this menu as well. In 
addition to statistics, the NEB can create a log for every print 50 
job, write the log to a work station disk, or clear the log file, 
as configured by CPINIT. 

If the system administrator selects the Logging Group 
option, then CPCONSOL directs a LAN request for the log 
file to the targeted NEB via the LAN interface. At the NEB, 55 
CPSOCKET receives the request and, since CPSOCKET 
stores the log file on the printer, requests the log file from the 
printer via the bi-directional SCSI interface. The NEB 
retrieves the log file from wherever it is stored (such as its 
disk 114) and provides the file to CPSOCKET via the 60 
bi-directional SCSI interface. CPSOCKET then puts the log 
file onto the network via the LAN interface for receipt by 
CPCONSOL. 

The log file includes values for the statistics which are 
divided into three categories: Daily, Cumulative, and Aver- 65 
age. Daily shows the values for the current day. Cumulative 
shows the totals for all days since last reset, or since 



[Application Control (Step S1514)] 

Application control allows CPCONSOL to view the cur- 
rent configuration of the NEB within the network (as either 
CPSERVER or CRPRINTER) (Step S1515) and to activate/ 
deactivate or modify and store that application (Step S1516). 
Access to the targeted NEB is provided via the LAN 
interface which responds to the CPCONSOL request by 
putting a result code on the LAN interface. 
[Printer Status (Step S1517)] 

This menu allows CPCONSOL to display the current 
status of the printer attached to the NEB (Step S1518), and 
to modify and store the new printer status (Step S1519). 
CPCONSOL directs a status request to the targeted NEB via 
the LAN interface. At the targeted NEB, CPSOCKET 
receives the status request and sends a request for the needed 
status information to the printer via the bi-directional SCSI 
interface. CPSOCKET receives the status information from 
the printer over the bi-directional SCSI interface and directs 
the information back to CPCONSOL where it is displayed 
on the system administrator's PC 14. 

There are 29 possible status conditions, "NORMAL" 
being the most common, as summarized in Table 8. 



TABLE 8 



Status 



Meaning 



NORMAL 

OFFLINE 

ENGINETEST 

MAINTRUNN1NG 

PAPEROUT 

PRJNTEROPEN 

PAPERJAMx 

NOEPCART 



On-line, ready to print or 
printing 

Off-line, not ready to print 
Engine test detected 
Maintenance program running 
Paper tray is empty. 
The printer top is open 
Paper is jammed at location 
"x" 

No EP cartridge is present 
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TABLE 8-continued 



Status 


Meaaing 


TONERLOW 


The toner cartridge is low 


ULFEED 


U-L feed 


LOADx 


Your paper is loading 


LOADnn 


Load paper "nn" 


FEEDx 


Feed Paper [x = message] 


FEEDnn 


Feed paper "nn" 


OCx 


CaPSL output call 




[n = message] 


SETUPPER 


Set to upper tray 


TRAYFULL 


Paper output tray is full 


DA f"lC T7T TI I 


The page is full 


LINEERROR22 


22 line error (see printer 




manual) 


UNEERROR40 


40 line error (sec printer 




manual) 


DLMEMORYFULL 


Download memory full 


WKMEMORYFULL 


Working memory full 


JOBREJECT 


Job has been rejected 


PRINTCHECK 


Print check error 


OPTREMOVAL 


Option removal 


FONTFULL 


Font configuration are full 


WARMINGUP 


Printer is in warmup 


SERVICE CALL 


Service call is needed 


TRANSIENT 


A transient, unidentified 




error occurred 



4j. NEB Responses To Status Inquiry Using CPSOCKET 

CPSOCKET is an application program which runs out of 
DRAM 220 on the NEB 2 in the multi-tasking soft-time 
environment provided by the non-preemptive MONITOR. 
CPSOCKET causes SAPSERVER to monitor the NEB's 
broadcast socket on the LAN for broadcasts from client 
programs such as CPINIT, CPCONSOL and DOWN- 
LOADER. 

CPSOCKET is responsible for the internal configuration 
of the NEB, such as configuration as either a PSERVER or 
an RPRINTER. Configurations are set at the request of 
CPINIT, as described above, but it is CPSOCKET that 
receives those configuration commands and physically alters 
NVRAM 228. 

CPSOCKET also maintains a table of default settings for 
the device environment (that is, a guaranteed safe 
environment, see section 4m below), downloads the basic 
configuration information for the printer and for the NEB 
(for example, fonts and emulations) at device power-up (see 
section 4d above), provides device status information, 
statistics, and log information in response to CPCONSOL 
requests, and provides reset, re-boot, and firmware down- 
load capabilities. 

FIGS. 16A and 16B comprise a detailed flow diagram 
showing operation of the CPSOCKET program. In Step 
SI 601, after successful power-on-self-test (POST), micro- 
processor 216 transfers the CPSOCKET program module 
from its storage locations in EPROM 222 into appropriate 
storage locations in DRAM 220. During transfer, micropro- 
cessor 216 configures the CPSOCKET program in accor- 
dance with the configuration information for the 
CPSOCKET program stored in NVRAM 228. Thus, for 
example, it is possible to selectively activate certain portions 
of the CPSOCKET program module in accordance with 
desired levels of complexity, those desired levels of com- 
plexity being stored in NVRAM 228. 

In Step S1602, the NEB commences execution of the 
CPSOCKET from DRAM 220. CPSOCKET is executed in 
a multi-tasking soft-time environment by the non- 
preemptive MONITOR which permits non-preemplive 
execution of other application programs such as CPS- 
ERVER without letting one application program seize con- 
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trol of the microprocessor to the exclusion of other appli- 
cation programs. 

In Step S1603, CPSOCKET broadcasts its existence over 
the LAN interface via service advertising protocol broad- 

5 casts (SAPSERVER) which contain a proprietary socket 
number (see section 4g above). Because other servers are 
operating in the multi-tasking environment established in 
Step S1602, and because the Netware®-compatible software 
only permits a single non-fileserver server to advertise from 

10 a single network node such as the NEB, CPSOCKET 
broadcasts its SAP advertisements via the SAPSERVER 
program. As described more fully above in paragraph 4g, the 
SAPSERVER program permits two network servers to 
broadcast from a single network node even when the net- 

15 

work supports only single servers for each network node. 

In Step S1604, CPSOCKET receives a broadcast request 
from a client, for example, CPINIT or CPCONSOL on 
proprietary socket 453. CPSOCKET responds to the client 

20 (Step SI 605) with an IPX packet on the same socket. 

In Step SI 606, the client establishes direct SPX commu- 
nication with CPSOCKET over a socket number that is 
pre-assigned to CPSOCKET, here socket number 83B4 for 
communication or 83B5 for connection. In accordance with 

25 that direct connection, CPSOCKET receives and interprets 
client requests and/or commands that are received over the 
LAN interface, monitors the status of the printer over the 
bi-directional SCSI interface, receives and sends status 

30 commands and/or inquiries to the printer via the 
bi-directional SCSI interface, reconfigures the NEB and the 
NEB configuration parameters, and sends requested infor- 
mation to the client via the LAN interface. These steps are 
described more fully below in connection with Steps SI 607 

35 through S1620 of FIGS. 16A and 16B. 

In more detail, in Step S1607, if CPSOCKET determines 
that a configuration command has been received, then flow 
advances to Step SI 608 in which the configuration com- 

40 mands are executed and the result provided via the LAN to 
the client. Configuration commands are listed in Table 9 and 
generally pertain to the configuration of the NEB board as 
either a CPSERVER or an CRPRINTER in accordance with 
configuration commands initiated by the CPINTT program. 

45 



TABLE 9 



50 





Configuration Commands 




Data 


Reference 


Command 


(CPINTT — CPSOCKET) 


(CPSOCKET — CPINIT) 


request for 


none 


current NEB settings 


current 




(CPSERVER; RPR INTER/ 


configuration 




LPR) 


reconfigure/ 


Desired 


new configuration 


deconfigure 


Configuration 


confirmation 


activate/ 


none 


confirmation 


deactivate 






application 






reset 


none 


confirmation 


re-boot 


none 


none 



If in Step S1609, CPSOCKET determines that a device 
information command has been received, then flow 
advances to Step SI 610 in which those device information 
65 commands are executed and the results provided to the LAN 
interface. In general, device information pertains to the 
interface, control status, font set and environmental settings 
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of the printer 4 attached to NEB 2. Device information 
commands in Step S1610 permit reading printer device 
information, setting printer device information, reading 
default settings for that information, and resetting the default 
settings to desired values. Device information commands 
are detailed in Table 10. 

TABLE 10 

Device Information Commands 



Command 



Data 

(CPCONSOL - 
CPSOCKET) 



request for 

interface 

status 

request for 

control 

status 

request for 
font status 
request for 
layout status 

request for 
quality and 
common 
environment 
status 
request for 
duplex status 
request for 
miscellaneous 



request for 
default 
control 
status 

request for 
default font 
status 
request for 
default 
layout status 
request for 
default 
quality and 
common 
environment 
status 
request for 
default 
duplex status 
request for 
default 

miscellaneous 
printer info 



set control 



set font 



set quality 
and common 
environment 
set duplex 



none 
none 



none 
none 



new printer 
control 

information for 
CPCONSOL "control" 
menu 

new printer layout 
(portrait/landscape, 
etc.) 

new printer macros 



new printer duplex 



Response 
(CPSOCKET - 
CPCONSOL) 



interface status 



printer control 
information for 
CPCONSOL 
"control" menu 
printer font set 

printer layout 
(portra it/la ndscape, 
etc.) 

printer macros 



printer duplex 
mode 

miscellaneous 
printer info 
(collation, 
stapling, paper 
folding, paper 
trays, etc.) 
default printer 
control 

information for 
CPCONSOL 
"control" menu 
default printer 
font set 

default printer 
layout (portrait/ 
landscape, etc.) 
default printer 
macros 



default printer 
duplex mode 

default 

miscellaneous 
printer info 
(collation, 
stapling, paper 
folding, paper 
trays, etc.) 
confirmation 



confirmation 



confirmation 



confirmation 
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TABLE 10-continued 



Command 



Device Information Commands 

Data Response 
(CPCONSOL — (CPSOCKET - 

CPSOCKET) CPCONSOL) 



10 miscellaneous 
printer info 



set default 
control 



set default 
layout 

set default 
quality and 
common 
environment 
set default 
duplex 
set default 
miscellaneous 
printer info 



20 



25 



mode 

new miscellaneous 
printer info 
(collation, 
stapling, paper 
hold, paper trays, 
etc.) 

default printer 
control 

information for 
CPCONSOL "control" 
menu 

default printer 
layout (portrait/ 
landscape, etc.) 
default printer 
macros 



default printer 
duplex mode 
default 

miscellaneous 
printer info 
(collation, 
stapling, paper 
holding, paper 
trays, etc.) 



confirmation 



confirmation 



confirmation 



confirmation 



confirmation 
confirmation 



If in Step S1611, CPSOCKET determines that a configu- 
ration parameter command has been received, then flow 

35 advances to Step S1612 in which CPSOCKET executes the 
received command and provides the result via the LAN to 
the client. As shown in Table 11, configuration parameter 
commands pertain generally to parameter values stored in 

40 the NEB concerning time, date, safe printer environment 
information, logging options, log file size, etc. 



TABLE 11 
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Configuration Parameter Commands 

Data Response 

(CPINIT - CPSOCKET) (CPSOCKET — CPINIT) 



request for 


none 


configuration 


current 




parameters (e.g. 


configuration 




time, data, safe 


parameters 




printer environment 
info, logging 
options, etc.) 


set new 


configuration 


confirmation 


configuration 


parameters (e.g. 




parameters 


time, data, safe 
printer environment 
info, logging 
options, etc.) 





65 



If in Step S1613 CPSOCKET determines that a NEB 
application program command has been received, then flow 
advances to Step S1614 in which CPSOCKET provides 
information on the current application program, namely 
RPRINTER, PSERVER, or LPR (for UNIX). Application 
program information generally includes server name, file 
server queue, device ID, etc., as detailed in Table 12. 
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TABLE 12 



TABLE 14 



Application Program Information 

Data Response 
Command (CPINTT -* CPSOCKET) (CPSOCKET - CPINIT) 



request for 
CRPR INTER 
info 
set 

CRPRINTER 
info 

request for 
CPSERVER 
info 
set 

CPSERVER 
info 

request for none 
CLPR info 

set CLPR info new CLPR info 



new CRPRINTER info 



new CPSERVER info 



CRPRINTER info 



confirmation 



CPSERVER info 



confirmation 



CLPR info 



confirmation 



35 
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If in Step S1615 (FIG. 16B) CPSOCKET determined that 
a NEB/printer statistic command has been issued, then flow 
advances to Step S1616 in which CPSOCKET interrogates 
the printer through the bi-directional SCSI interface to 
obtain needed printer statistics. The statistics correspond to 
the network group displays described above in connection 
with CPCONSOL, as well as to print job statistics such as 
the total number of pages printed, the total number of jobs, 
the total number of off-line time, etc. The job statistics 
correspond to the logging group described above in connec- 
tion with the CPCONSOL program. Specific examples of 
the commands executed in the NEB/printer statistics com- 
mands are set forth in Table 13. 

TABLE 13 

Statistics Commands 



Command 


(CPCONSOL — 
CPSOCKET) 


Response 

(CPSOCKET — CPCONSOL) 


request 


none 


network statistics 


network 




for CPCONSOL 


statistics 




"NETWORK" menu 


clear 


none 


confirmation 


network 






statistics 






request 


none 


job statistics for 


job 




CPCONSOL "LOGGING" 


statistics 




menu 


clear job 


none 


confirmation 


statistics 







If in Step S1617 CPSOCKET determines that a logging 
command has been received, then flow advances to Step 
SI 618 in which CPSOCKET obtains the log file from the 
printer disk 114 via the bi-directional SCSI interface, and 
sends the log file to the client via the LAN interface. 
Logging commands are summarized Table 14. 
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Logging Commands 





Data 




Com- 


(CPCONSOL — 


Response 


mand 


CPSOCKET) 


(CPSOCKET -* CPCONSOL) 


request 


block # 


next block number of 


log file 




log file and log data 


clear 


none 


confirmation 


log 






request 







If in Step S1619 CPSOCKET determines that a download 
command has been received from the LAN interface, then 
flow advances to Step S1620 in which CPSOCKET executes 
the download request, for example, by receiving download- 
able code and storing it in specified locations in DRAM 220, 
by providing check-sum data for the downloadable code, 
and by flashing the downloadable code into EPROM 222. 
Some of the more important download commands are sum- 
marized in Table 15. 



TABLE 15 
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Download Commands 



Data 



Command 


(DOWNLOAD - 
CPSOCKET) 


Response 

(CPSOCKET - DOWNLOAD) 


download 


code 


confirmation 


request 
call request 


checksum, 


confirmation 


flash 


starting address 
checksum 


confirmation 


EPROM 







4k. Logging Peripheral Statistics 

As described earlier with respect to FIG. 5 A, Steps S9 
through S12 comprise an automatic logging function in 
which peripheral statistics (e.g. number of pages printed per 

40 day) and error events are automatically logged (stored) for 
later retrieval; and wherein the logging level (statistical 
resolution) may be varied by the network administrator. In 
general, the network administrator may select a logging 
level, and then extract printer statistics and error events from 

45 the log file at any lime. The network administrator's portion 
of such functions has been described above in paragraph 4i, 
and reference may be had to the discussion and tables set 
forth therein, especially Table 7 which indicates the content 
of the log file depending upon the logging level set by 

50 CPINIT. 

As background, few LAN peripherals maintain their own 
statistics, but the NEB 2 includes the capability of logging 
the current status and daily statistics of printer 4 at midnight 
of each day. This relieves the system administrator from 

55 having to remember to do this on a daily basis. The status 
and statistics data may be stored in printer hard disk 114, 
printer NVRAM 111, NEB DRAM 220, or in the NEB 
NVRAM 228. The location of the stored log file may be 
selected by the network administrator depending upon the 

60 remaining memory capacity of each of those memories, and 
the statistics required by the logging level selected by the 
network administrator. For example, if the printer has a hard 
disk, the network administrator may choose the fairly- 
detailed "JOB", logging level so that voluminous statistics 

65 may be retained. On the other hand, if the printer has no hard 
disk, the network administrator may choose the less-detailed 
"ERROR" logging level so that less storage space is 
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required. If the log file is filled, new error data will merely where a one minute timeout is awaited. However, if the 

wrap around in the memory replacing old error data with ERROR logging level has not been selected, it is determined 

new error data. in Step S1704 that the JOB logging level has been selected. 

The NEB will automatically store printer statistics such as In this case, Step S1705 stores the job start and job end times 

pages printed, jobs printed, off-line time, and print time each 5 to the log file. At Step S1706, a one minute timeout is 

night for access for the system administrator at a later time. awaited whereafter Step S1707 queries the printer for error 

The statistics can be used to anticipate replacement of events and saves such events to the log file. Thus, when 

consumable printer supplies, such as toner, and to monitor either the ERROR or JOB logging levels have been selected, 

user behavior such as leaving the printer off-line for the board queries the printer every minute for error events 

extended periods of time. 10 and stores such error events in the log file. 

In general, the logging function is accomplished by the Step S9 waits for midnight whereupon the NEB queries 

printer controller board always knowing what time it is. the printer for its daily statistics at Step S10 FIG. 15B). If 

When a printer/controller board is first powered on, the midnight has not been reached in Step S9, the procedure 

board finds the nearest server and requests the time. The returns to Step S1702 where it is determined which logging 

board continues to do this every minute. When the day of the 35 level has been selected. 

week changes, the board automatically requests the printer In Step Sll, the daily printer statistics are calculated 

to report its page count. The board then calculates the daily utilizing the printer statistics received in Step S10. 

statistics and stores them either to the printer hard disk or to Thereafter, in Step S12, the daily statistics and the error 

the board NVRAM. These statistics are stored and available events are stored in the printer hard disk 114 and/or the 

to the external network program CPCONSOL that can 20 printer NVRAM 111, and/or the NEB NVRAM 228. Note 

display them to a screen or save them to an external file. here that the network administrator may select to store 

As described above in paragraph 4i, the network admin- logging statistics and error events in any combination of 

istrator may select four logging levels: NONE; AUTO; memories, providing further flexibility to the LAN. 

ERROR; and JOB. At the NONE level, no logging statistics The logging functions discussed above are quite signifi- 

are maintained (although they may still be calculated every 25 cant in making the printer an interactive and responsive 

minute and temporarily kept in NEB DRAM 220). At the member of the LAN since the SCSI connection between the 

AUTO level, daily statistics are maintained for printer NEB and the printer is capable of extracting volumes of 

features such as printing days, pages, jobs, off-line time, and specific data from the printer. 

print time. The number of cumulative pages printed is 41. Multi-tasking Independently Executable Programs 

determined by the printer, but the other statistics are deter- 30 As briefly described earlier with respect to Step S20 of 

mined by the NEB. FIG. 5B, the NEB EPROM 222 stores a MONITOR pro- 

The ERROR logging level maintains the daily statistics gram which is a mechanism which supports multi-tasking in 
discussed above, and also error conditions in the printer and the run-time environment while permitting synchronous 
also errors that occur in an application (i.e. CPSERVER). operation in a de-bug environment. MONITOR permits 
The NEB queries the printer every minute for such error 35 currently-called tasks to be performed on a non-preemptive 
conditions. Such printer error conditions may include: off- basis while the NEB awaits real-time interrupts from either 
line; out-of-paper; printer-is-open; paper-jam; no-toner- the LAN (for CPSERVER or CPSOCKET) or through the 
cartridge; toner-is-low; printer feed and load errors; tray-is- SCSI interface (e.g., when status information is being pro- 
full; line errors; print-job-rejected; font-is-full; service call; vided from the printer to the NEB in response to a 
etc. Application errors may include: fileserver down; pri- 40 previously-received status request from the LAN). Thus, 
mary fileserver unavailable; CPSERVER running else- MONITOR permits all currently-executing tasks to be per- 
where; IPX not installed; etc. formed simultaneously by sharing use of the microprocessor 

The JOB logging level maintains the daily statistics and 216. Of course, all soft-time applications, including MONI- 

error conditions noted above and also maintains job start and TOR itself, are interruptable by real-time events, 

job end information, which are determined by the NEB. Of 45 FIG. 18 is a notional flowchart of a sequence of events 

course, the number and types of logging levels, and the data which may occur in order to illustrate the multi-tasking 

retained in each logging level may be varied according to the operation within the NEB. At Step SI, power is applied to 

particular peripheral and the particular LAN in which the the NEB, and the MONITOR program is downloaded from 

NEB is installed. EPROM 222 to DRAM 220 in Step S1801. For example, the 

FIGS. 17A and 17B comprise a flow chart showing the 50 following modules are downloaded together with MONI- 

overall operation of the automatic logging function within TOR: SCSI Driver; Link Support Layer; Network Driver; 

the NEB. Reference may also be had to FIG. 5A and Table Prescan; IPX/SPX; Customized NETX; SAPSERVER; 

7 noted above. At Step SI, power is applied to the NEB and CPSOCKET; and Print Applications (see FIG. 6). 

at Step S8, the timer module finds the nearest server and If, at Step S 1802, print data is received from file server 30, 

requests the time. At Step S1701, it is determined whether 55 CPSERVER will begin processing the received job data in 

the NONE logging level has been selected. If the NONE preparation for transmission to the printer 4. Processing of 

logging level has been selected, the process skips to the end such print information is now in the "soft-time" 

of the flowchart where a return is made to the overall flow environment, and Step S1803 determines whether a relin- 

diagram of FIGS. 5A, 5B and 5C. quish interrupt has been received from the program process- 

If the NONE logging level has not been chosen in Step 60 ing the print data. If a relinquish interrupt has been reached 
SI 701, Step S1702 determines whether the AUTO logging at Step S1803, execution of the currently-executing module 
level has been selected. If the AUTO logging level has been is stopped and control is returned to MONITOR at Step 
selected, the process proceeds to Step S9 where midnight is S1804. MONITOR saves the state of the interrupted task in 
awaited. However, if the AUTO logging level has not been DRAM 220. However, if the relinquish interrupt has not 
selected, Step S1703 determines whether the ERROR log- 65 been reached at Step S1803, the process proceeds to Step 
ging level has been selected. Where the ERROR logging S1805 where it is determined whether the currently- 
level has been selected, the process skips to Step S1706 executing module has reached an end. If the end has not been 
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reached in Step S1805, the program waits until another 
relinquish interrupt is reached in Step S1803. 

If the currently-executing module has been stopped at 
Step S1804, or if the currently-executing module has 
reached an end at Step S1805, it is determined at Step S1806 
whether data has been received which requires the execution 
of another software module, e.g., where data is received over 
the SCSI interface in response to a previously-issued request 
for printer status. If it is determined in Step S1806 that such 
data has been received, Step S1807 begins execution of 
another application module using the newly-received data. 

At Step 1808, it is determined whether a relinquish 
interrupt has been reached in the second application module. 
If such an interrupt has been reached, the second application 
will stop execution and pass control to MONITOR which 
stores in DRAM 220 the state of the just-interrupted second 
module at Step S1809. However, if the relinquish interrupt 
in the second module has not been reached at Step S1808, 
it is determined at Step S1810 whether the end of the second 
module has been reached. If the end has not been reached, 
the program merely awaits the relinquish interrupt at Step 
S1808. If it is determined that the second module end has 
been reached in Step S1810, Step S18U determines whether 
the first module end has been reached. Where the end of the 
first module has not been reached, but the end of the second 
module has been reached, the process returns to waiting for 
a relinquish interrupt in the first application module at Step 
S1803. If both the first and second modules have reached 
their end at Step S1811, control will return to the MONITOR 
program in order to execute other newly-received soft- time 
tasks. 

After the second application module has stopped execut- 
ing due to reaching a relinquish interrupt therein, control is 
passed to MONITOR which, after storing the state of the 
interrupted module in DRAM 220 (Step S1809), will recom- 
mence execution of the first module in Step S1812, and 
continue execution of the first module until another first 
module relinquish interrupt is reached at Step S1803. 

Thus, the non-preemptive multi-tasking allocation of the 
microprocessor resources allows processing of a number of 
tasks in parallel on a near real-time basis. 
4m. Placing The Printer In A Default Configuration 

As discussed above with respect to Step S25 in FIG. 5C, 
the NEB will ensure that the printer is set to a known, default 
configuration at the beginning or end of a print job. The NEB 
does this by downloading to the printer's non-volatile 
memory (either hard disk 114 or NVRAM 111) a default 
configuration code which indicates the default environment 
(e.g. portrait mode, 10 point type, Roman lettering, etc.) in 
which the printer should be left at the conclusion of a print 
job. Upon receiving a print data stream from the LAN, the 
NEB retrieves the configuration code from the printer's 
non-volatile memory, appends the configuration code to a 
block of print data as an escape sequence, and then down- 
loads the print job block with appended escape sequence to 
the printer. The printer will then conduct a printing 
operation, and (based on the escape sequence) will leave the 
printer in the desired default configuration. 

Novell NetWare® software includes the ability to reset a 
network printer in a default environment after every print 
job. It does this by having the file server 30 install what 
amounts to a fake print job at the head of the print job itself. 
However, the exact printer escape sequences necessary to set 
particular printer default configurations reside in a database 
on the network, and not within the printer itself. Therefore, 
if it is desired to operate UNIX on the LAN, or where there 
is a problem with the file server itself, the printer may not be 
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restored to a default configuration which ensures that the 
next print job will be printed with the printer in a known 
configuration. 

A method of guaranteeing a printer default environment 

5 using the NEB operates on the difference that the printer 
reset state configuration and requisite escape sequence 
instructions reside within the printer itself, and the printer 
itself is responsible for resetting its own environment within 
print jobs. Thus, the printer reset feature is available without 

10 depending upon any device external to the printer. 
Furthermore, the initial default configuration may be loaded 
and subsequently modified from a remote location over the 
LAN through the NEB's serial or parallel interfaces. 
The configuration code may be sent to the NEB through 

is the CPCONSOL program, as discussed above in section 4i. 
It may be convenient to store a plurality of default 
configuration codes in the printer non-volatile memory in 
order to allow the network administrator great flexibility for 
printer usage on the LAN. For example, print jobs received 

20 from an engineering source may require the printer to 
default to a portrait mode, whereas print jobs received from 
accounting may require that the printer be left in a spread 
sheet mode. Thus, by ensuring a known default 
environment, any of a number of LAN sources may utilize 

25 the printer for their specific jobs. 

FIG. 19 depicts a more detailed flowchart for setting the 
printer default configuration. At Step SI, power is applied to 
the NEB, and at Step S22, the NEB accesses the LAN file 
server for active print queues and downloads print data to the 

30 DRAM 220. 

If the printer non-volatile memory stores more than one 
default configuration code, it may be necessary to first 
determine what type of data is being transmitted from the 
LAN in order to determine which default configuration the 

35 printer should be left in. Therefore, Step S9101 determines 
the LAN source of the print job, and Step S1902 retrieves the 
appropriate default configuration code from the printer, 
which code corresponds to the determined LAN source. 
At Step S1903, the NEB assembles blocks of image data 

40 and designates a start-of-print-job and an end-of-print-job 
for each print job. At Step S1904, the NEB microprocessor 
216 appends to a print job an escape sequence which 
corresponds to the retrieved configuration code. Preferably, 
the escape sequence is appended to the beginning of the print 

45 job, but it may be appended to the end of the print job, or to 
both the beginning and end of the job. Then, at Step S1905, 
the print job, with appended escape sequence, is transferred 
to the printer, and the printer then renders print according to 
the received print job. When a print job is completed after 

50 Step S24, the printer will set itself to a default environment 
at Step S25, which environment corresponds to the default 
configuration code retrieved in Step S1902. Therefore, the 
printer will be left in a default environment which ensures 
that the next print job will begin with the printer in a known 

55 configuration. 

Thus, a robust and efficient hardware and software solu- 
tion has been found for ensuring that the printer itself stores 
a default configuration and is responsible for placing itself in 
a default condition at the end of every print job. 

60 4n. Downloading Executable Files Into The NEB From A 
Remote LAN Location 

The downloading of executable files from the LAN to 
DRAM 220 will be discussed in more detail with respect to 
the flow diagram in FIG. 20, and with respect to the 

65 discussion above of Step S30 in FIG. SC. 

NEB 2 is configured initially prior to shipping. However, 
NEB 2 can be reconfigured subsequently by sending updated 
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executable files across the LAN from the network adminis- 
trator's PC 14 to the NEB 2. Furthermore, network admin- 
istrator can remotely alter the executable files stored in 
DRAM 220 of NEB 2, as desired. 

The process by which executable files can be altered in 
DRAM 220 will be discussed in detail with respect to FIG. 
20. 

After the board has been powered-up at Step SI, the flow 
proceeds to Step S2001 at which point the network admin- 
istrator activates a DOWNLOADER program to broadcast 
over the LAN a request for identification of all NEB devices 
having a particular configuration whereupon flow advances 
to Step S2002. 

In Step S2O02, the DOWNLOAD program determines 
whether any target NEBs have responded. If in Step S2002 
it is determined that no target NEBs have responded, flow 
returns to Step S2001 in which the DOWNLOAD program 
rebroadcasts the request with new target information and 
then flow advances to Step S2002. 

If in Step S2002 a target NEB responds, flow advances to 
Step S2003. 

In Step S2003, the SAPSERVER program responds with 
the unique network IDs and the unique socket numbers 
assigned to each NEB (see section 4g above). This location 
information is collected, the network administrator selects a 
particular NEB to download an executable file, and com- 
munication is established with the target NEB. 

Upon selecting the target NEB, the network administrator 
downloads new operational files and a special packet con- 
taining a checksum value to DRAM 220 across the LAN in 
Step S2004 whereupon flow advances to Step S2005. 

In Step S2005, microprocessor 216 performs a checksum 
operation on the newly loaded operational files and com- 
pares the checksum value with a checksum value sent in the 
special packet which is stored in DRAM 220 after the 
operational files have been stored. 

If the checksum value does not equal the checksum value 
in the special packet, then flow advances to Step S2006 at 
which point microprocessor 216 notifies the network admin- 
istrator that the checksum value for the new operational files 
is incorrect and at which point microprocessor 216 may 
purge the files from DRAM 220. 

If in Step S2005 the checksum value is verified, then flow 
advances to Step S2007 at which point the executable files 
are acted on by microprocessor 216. 

Thus, the network administrator can alter the operation of 
NEB 2 by remotely sending new operational files to be 
stored and to be executed from DRAM 220, 
4o. Loading Independently Executable Modules In ROM 

As described above in FIG. 5C with respect to Step S32, 
when a binary ROM image is to be loaded into EPROM 222, 
a plurality of independently-executable modules are 
assembled, ordered, and prepared for flash to EPROM 222. 
The assembly and ordering of the modules is presently 
carried out on a DOS PC, but may be carried out in the NEB 
itself. An advantage of assembling the independently 
executable modules in a PC is that the modules may be 
constructed and/or modified in a DOS environment. 

NEB firmware comprises a number of separately linked 
modules, one of which contains permanently ROM-resident 
code which receives control at power-up and provides 
self-test, loading of other modules into DRAM 220, and 
basic I/O services. The other modules residing in the 
EPROM 222 must be copied to DRAM 220 before execu- 
tion. There are two types of such modules, the first of which 
includes programs which are essentially drivers which 
receive control when loaded, initialize, and then exit, 
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remaining resident. The second type of such modules are 
application programs, each of which executes a specific set 
of functions. 

In FIG. 21, the NEB is powered-up at Step SI. At Step 

5 S2101, a utility resident in the PC reads from its RAM a 
configuration file containing the names of all modules to be 
placed in the ROM image. The configuration file is used to 
select from RAM, at Step S2102, those modules which are 
going to be flashed to EPROM 222. 

3Q At Step S2103, the utility writes a header for the first 

3 module, the header identifying that module, describing the 
module attributes, and including a pointer which points to 
the immediately succeeding module. This pointer aides in 
the ordering of the modules in a specific order prior to 
loading. At Step S2104, it is determined whether the last 

35 module identified by the configuration file has been selected. 
If the last module has not been selected, the process loops to 
Step S2103, where the header is written for the next module. 

When the last module has been selected in Step S2104, 
the utility appends the ROM -resident code to the end of the 

20 image program (at Step S2105) so that upon power-up, the 
initialization code resides at the address expected by micro- 
processor 216. 

When the ROM binary image is thus constructed, the 
image may be downloaded to one portion of the memory 

25 area of NEB DRAM 220, and then flashed to EPROM 222, 
as will be discussed in greater detail in section 4q below and 
with respect to the detailed discussion of FIG. 5C, Step S36. 
4p. Protecting The EPROM During A Flash Operation 
FIG. 22 is a block diagram showing the functional con- 

30 struction of the EPROM flash protection circuitry resident 
on the NEB. The EPROM flash protection circuit includes 
microprocessor 216 coupled to data bus 250 and address bus 

251. Also connected to data bus 250 and address bus 251 is 
DRAM 220. DRAM 220 is capable of storing a ROM 

35 firmware image downloaded from a remote LAN device into 
one portion of its memory area (see section 4o above), and 
application process steps into another portion of its memory 
area. Also coupled to data bus 250 and address bus 251 are 
EPROM 222, latch 252, and PAL 253. D-type flip-flop 254 

40 is connected to latch 252 and PAL 253. During operation, 
flip-flop 254 receives as its clock input an output signal from 
PAL 253 and as its data input, an output signal from latch 

252. Latch 252 and PAL 253 are also connected to DC-DC 
converter 212, and DC-DC converter 212 is connected to 

45 transistor switch 255. When activated by latch 252, DC-DC 
converter 212 sends +12 volts to the input emitter of 
transistor switch 255. Flip-flop 254 is also connected to 
transistor switch 255 to provide the necessary input to 
open/close switch 255. 

50 The operation of the EPROM flash protect circuitry will 
now be explained in more detail with reference to FIG. 22. 
Upon power-up, output of latch 252 will be low and flip-flop 
254 will be reset. In this manner, the output signal PROG1 
from latch 252 will be low and voltage from DC-DC 

55 converter 212 will be directed to sink current to a ground 
state. At power-up, flip-flop 254 is reset so that its output is 
set low thereby opening transistor switch 255. 

With transistor switch 255 in an open state, Vpp pin of 
EPROM 222 will be held at 0 volts preventing any data from 

60 being accepted or a flash operation from being performed. 
That is, for a flash operation to occur in EPROM 222, the 
Vpp pin must reach a level of at least +11.4 volts, which is 
a requirement set by the EPROM manufacturer's specifica- 
tions. However, in order to achieve this voltage level, the 

65 following two programming steps are required. 

First, when a new ROM firmware package is received in 
DRAM 220, microprocessor 216 receives a command to 
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flash EPROM 222, by generating an I/O write to address 360 
hex with data bit 7 high (80 hex). In this manner, DC-DC 
converter 212 can be first turned on. 

As shown in Tables 16 and 17, address 360 hex corre- 
sponds to control register 230 which is used to control 
read/write operations to NVRAM 228. As shown in Table 17 
below, when 360 hex is sent with bit 7 high/low, the address 
corresponds to an operation of DC-DC converter 212. 



TABLE 16 


I/O SELECT 


ADDRESS 


LAN CHIP 


300-30F HEX (R/W) 


DMA DATA LATCH 


310-317 HEX (R/W) 


LAN CHIP SOFT RESET 


318-31F HEX (R) 


SCSI CHIP REGISTER 


320-32B HEX (R/W) 


STATUS REGISTER 


330 HEX (R) 


CONTROL REGISTER #1 


360 HEX (R/W) 


CONTROL REGISTER #2 


366 HEX (X) 


NMILCK 


200 HEX (W) 


LAN ADDR. ROM 


340-35F HEX (R) 
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Then the EPROM 222 is flashed with the new ROM 
firmware image stored in DRAM 220. Once the new ROM 
firmware image is stored in EPROM 222, NEB 2 can be 
re-booted from the new ROM firmware image. 

The operation of the EPROM protection circuit will now 
be explained with reference to FIG. 22 and the flowchart of 
FIG. 23. 

In Step S2301, a new ROM firmware image is received by 
NEB 2 across the LAN and loaded into DRAM 220. 
Microprocessor 216 receives a command to flash EPROM 
222 in Step S2302. In Step S2303, microprocessor 216 sends 
out an I/O write command to PAL 253 and outputs address 
360 hex with bit 7 high. Flow advances to Step S2304 in 
which bit 7 high activates latch 252 to output the PROG1 
signal. The PROG1 signal turns on DC-DC converter 212 

5 and +12 volts is output to transistor switch 255. In Step 
S2305, microprocessor 216 sends both an I/O read com- 
mand to PAL 253 and address 366 which is a PAL address. 
In response, PAL 253 outputs the PROG2 signal to clock 
flip-flop 254 which allows the PROG1 signal to be input at 

} its data input. Flip-flop 254 outputs the TRANSON signal to 
transistor switch 255 which allows +12 volts to pass from 



TABLE 17 



MSB LSB 



7 


6 


5 


4 


3 


2 


1 


0 



NVRAM CS(WRITE), DO(READ) 

NVRAM SKCWRTTE) 

NVRAM DI (WRITE) 

NOT USED 

NOT USED 

NOT USED 

DIAG.LED 1-ON 

0-OFF 

+1 2V DC CONVERTER 

l=ON 
0-SHUT DOWN 



After address 360 hex is output, microprocessor 216 
generates an I/O write command and sends a write select to 
PAL 253. PAL 253 detects a valid address, decodes it and 
activates latch 252. With bit 7 high in address 360 hex, the 
PROG1 signal is set high and output from latch 252 to 
DC-DC converter 212, When the PROG1 signal is received 
at DC-DC converter 212, it operates DC-DC converter to 
produce +12 volts. The +12 volts from DC-DC converter 
212 is sent to transistor switch 255, and which remains at its 
emitter until transistor switch 255 is closed. 

However, before +12 volts is allowed to pass through 
transistor switch 255, the second step must be executed. That 
is, microprocessor 216 outputs an I/O read command and 
outputs address 366 hex which corresponds to a PAL 
address. When microprocessor 216 generates both the com- 
mand and address, PAL 253 decodes the address and gen- 
erates a PROG2 signal. When the PROG2 signal is high, it 
will provide a clock input to flip-flop 254. 

Upon receiving the clock input, flip-flop 254 will input the 
PROG1 signal from latch 252 and then generate a TRAN- 
SON signal at its output. The TRANSON signal is output to 
transistor switch 255 which operates to close the switch that 
allows +12 volts at its emitter to pass through to its collector. 
At this point, +12 volts is sent from the collector of transistor 
switch 255 to the Vpp pin of EPROM 222. 

With +12 volts placed at the Vpp pin of EPROM 222, 
microprocessor 216 sends out an EPROM select signal. In 
order to prevent the new firmware image from being 
corrupted, EPROM 222 must first be cleared and erased. 



the collector of transistor switch 255 to the Vpp pin of 
EPROM 222. In Step S2306, microprocessor 216 clears and 
then erases EPROM 222. In Step S2307, microprocessor 
216 determines if EPROM 222 has been completely erased. 
If EPROM 222 is not completely erased, flow returns to Step 
S2307. 

After microprocessor 216 determines that EPROM 222 
has been completely erased, in Step S2308, the ROM 
firmware image is downloaded from DRAM 220 to EPROM 
222. Once the ROM firmware image is successfully loaded, 
in Step S2309 microprocessor 216 writes address 360 hex 
with bit 7 low. The PROG1 signal from latch 252 goes low 
and DC-DC converter 212 allows the voltage level to sink 
current to a ground state. 

In Step S2310, microprocessor 216 sends PAL 253 an I/O 
read command and a 366 hex address which permits the 
PROG2 signal to go low thereby clocking the flip-flop which 
outputs a low TRANSON signal which operates to open 
transistor switch 255. 

Thus, in Steps S2309 and S2310, +12 volts is removed 
from Vpp pin of EPROM 222 and the flash operation is 
ended. After the flash operation, microprocessor 216 deter- 
mines if a re-boot command has been received in Step 
S2311. If the re -boot command has been received, NEB 2 is 
re-booted in Step S2312 from the new ROM firmware image 
in EPROM 222. However, if no re -boot command is 
received, then flow ends. 
4g. Remotely Altering Firmware 

The method for remotely altering firmware in EPROM 
222 will be discussed in more detail below and with refer- 



45 
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ence to the flowchart illustrated in FIG, 24, Step S36 of FIG. 
5C, and section 4i above. 

Prior to shipping a NEB to a customer, the NEB is 
configured with the minimum number of executable files 
which permit the NEB to perform necessary functions. 
However, the NEB can be reconfigured subsequently by the 
customer. That is, a network administrator may download 
data from a remote LAN device, which data may contain 
anything from a patch code, to manufacturing test routines, 
to entire firmware updates to be downloaded to the EPROM. 

In more detail, NEB2 can be reconfigured by sending 
executable files across the LAN from the network adminis- 
trator's PC 14 to NEB 2. The network administrator can 
remotely alter the ROM firmware image in EPROM 222, as 
desired. 

In Step S2401, the network administrator activates a 
CPFLASH program that uses a MAC address as a command 
line parameter to target a specific NEB. CPFLASH issues a 
SAP broadcast request which is responded to by SAPS- 
ERVER running on the NEB. In Step S2402, CPFLASH 
waits for a response from the targeted NEB. If in the case 
where the targeted NEB does not respond in approximately 
15 seconds, the flow returns to Step S2401 and the broadcast 
is resent. However, in the case where the targeted server 
responds, flow advances to Step S2403. 

In Step S2403, the address and location of the targeted 
NEB is received, communication with the NEB having the 
matching MAC address is established, and a new ROM 
image firmware is downloaded over the LAN to DRAM 220. 

In Step S2404, the validity of the ROM firmware image 
is checked before proceeding to the next step. The validity 
of the ROM firmware image is verified against an image 
checksum which is sent in a special packet along with the 
download operation in Step S2403. If the checksum value 
does not match the checksum downloaded with the ROM 
image, then in Step S2405 the operator is notified of an error 
and the ROM firmware image in DRAM 220 is purged. 

If the checksum value is valid, then flow advances to Step 
S2406 at which point microprocessor 216 retrieves any data 
which is to be preserved, such as the MAC address, and 
stores the data within the proper locations in the new 
firmware image stored in DRAM 220. In this fashion, if the 
new ROM firmware image is defective, the NEB may still 
function since predetermined portions of essential ROM 
firmware are maintained. Once the essential portions of 
ROM firmware are preserved, flow advances to Step S2407 
at which point EPROM 222 is controlled to be cleared and 
erased a plurality of times, if required. After EPROM 222 
has been erased, in Step S2408 the new ROM image is 
loaded into EPROM 222. 

After the flash operation, microprocessor 216 determines 
if a re-boot command has been received in Step S2409. If the 
re-boot command has been received, NEB2 is re-booted in 
Step S2410. However, if no re-boot command is received, 
then flow ends. 

In Step S2404, the validity of the ROM firmware image 
may also be verified by comparing newly received firmware 
data with data previously stored in EPROM 222. For 
example, where EPROM 222 stores hardware indicators 
previously carried by PROM 232 (e.g., board manufacture 
date, board revision number, manufacturing facility, etc.; to 
be discussed in greater detail in section 5 below), such 
indicators may be compared with the same indicators in the 
newly-received ROM firmware image. This comparison 
may be made in addition to or in lieu of the checksum 
comparison discussed above. 

It is noted that a new MAC address may also be flashed 
into EPROM 222 at the same time a ROM firmware image 
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is flashed. However, it is preferable only to flash a MAC 
address prior to shipping, at the completion of NEB test. 
This feature is discussed in more detail with respect to 
Section 5 below. 
5 5. TEST 

Prior to installing the NEB in the printer, it may be tested 
to ensure the integrity of its hardware and software compo- 
nents. FIG. 25 depicts one test configuration which may be 
utilized to test the NEB 2. In FIG. 25, the NEB 2 is coupled 

10 to PCI 300 via a cable 302 coupled to the NEB serial port 
218. A printer 304 may be coupled to PCI 300 in order to 
print out test results. 

The NEB 2 is coupled to a test driver PC2 306 through an 
SCSI bus 308 and Ethernet LAN connections 310, 312. The 

35 PC2 306 includes an SCSI board 314 and a network con- 
troller board 316 so that it may simulate a printer and LAN 
entities (such as the network administrator's PC 14). The 
PC2 will act as a transponder, receiving and returning 
communications to and from the NEB 2, as commanded by 

20 the test programs input to the NEB from PCI 300 through 
the serial port 218. 

After power is applied to NEB 2, it performs the power- 
on-self-test operation. While the NEB 2 is performing each 
test operation in the POST, PCI 300 receives test checkpoint 

25 results across serial cable 302. 

Once it is determined that NEB 2 has satisfactorily 
completed POST, NEB 2 enters a "Ready For Download" 
state. In this state, NEB 2 waits for a period interval of 
approximately one second for further input instructions 

30 across any one of the input ports. 

While the NEB is in the download state, PCI 300 uploads 
test programs to the NEB through serial port 218. As NEB 
2 completes execution of each test program, it sends each 
test result back to PCI 300 for verification. If the next 

35 checkpoint is not received within a timeout period (e.g., 1 
second), it is determined that an error has occurred during 
the NEB test program, and an error signal is output by PCI 
300. The error signal may be indicated on a display at PCI 
300, or printed out on printer 304. 

40 On the other hand, if the next checkpoint received by PCI 
300 is not verified, then PCI 300 rescripts the test program 
(by adding further, more detailed test modules) in accor- 
dance with the received result. In this manner, PCI 300 can 
locate the problem and debug NEB 2. 

45 Some test programs may require NEB 2 to communicate 
with PC2 306 over either the SCSI bus 308 or one of the 
LAN connections 310, 312. For instance, in accordance with 
the test program, NEB 2 may request data from PC2 over the 
LAN connection 310. PC2 306 is configured to return 

50 appropriate responses to each communication from NEB 2, 
thereby effectively emulating the printer and the other LAN 
members. If the correct communication is returned from 
PC2 306, NEB 2 indicates a successful test by passing 
another checkpoint to PCI 300 through the serial port 218. 

55 A more detailed discussion of the method for testing NEB 
2 will be provided below with reference to the flowchart 
illustrated in FIGS. 26Aand 26B, and in accordance with the 
test configuration depicted in FIG. 25. 
When power is first applied to the NEB 2, NEB 2 executes 

60 the POST program from EPROM 222, in Step S2601. The 
POST program includes individual programs for testing 
component operation and software programming. After 
execution of an individual programs within POST, in Step 
S2602 a checkpoint is sent to PCI 300 to be verified. If a 

65 checkpoint is not sent after a predetermined period follow- 
ing the execution of an individual program or a returned 
checkpoint is incorrect, an error signal is sent out from PCI 
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300 in Step S2603. However, if all checkpoints are correct 
and received within a timely fashion, the process advances 
to Step S2604 where PCI 300 prepares to send test programs 
to the NEB. 

At Step S2605, the POST program is complete and NEB 
2 waits for instructions from across any one of the ports, 
preferably the serial port. The waiting period can be approxi- 
mately a one second window in which time PCI 300 should 
respond with the prepared text programs. In Step S2606, if 
PCI 300 does not respond by sending a test program to NEB 
2 within the time window, flow advances to Step S2607 
where the NEB enteres its normal operational mode. 

When the test program instruction set from PCI 300 is 
received in Step S2606, the instruction set, which includes 
further test programs, is stored (in Step S2608) on NEB 2 in 
DRAM 220. In Step S2609, PCI 300 activates the instruc- 
tion set and NEB 2 executes each test program within the 
instruction set. 

The test program instruction set may contain, in random 
order, test programs which require NEB 2 to configure PC2 
306 as a LAN peripheral device, or which require NEB 2 to 
configure PC2 306 as an SCSI peripheral device. In either 
case, after being configured, PG2 306 will respond to each 
communication from NEB 2, usually by merely returning 
data blocks sent by the NEB. 

Briefly, in Step S2610 (FIG. 26B) NEB 2 configures PC2 
306 as a LAN peripheral and PC2 306 responds by sending 
a response to NEB 2 which effectively performs a LAN 
loopback test by returning the data which it has received. 
NEB 2 will communicate with PC2 and receive simulated 
print job results. In Step S26H, the result of each block job 
is sent to PCI 300. PCI 300 determines if the test result is 
correct. In Step S2611, if it is determined by PCI 300 that 
the test result is incorrect, PCI 300 sends a re-scripted, 
branch test program (Step S2612) in accordance with the test 
result received in Step S2611. However, if no further branch 
test program exists, then in Step S2612 PCI 300 will stop 
LAN testing and output an error signal. 

Thus, in Step S2611, NEB 2 is tested for LAN commu- 
nications. Assuming NEB 2 successfully passes each LAN 
communication test, flow advances to Step S2613 at which 
point PC2 306 is configured as an SCSI peripheral device 
and performs SCSI loopback tests by returning the data 
which it has received. In Step S2614 the results of the tests 
are sent to PCI 300 and if the results are incorrect, PCI 300 
similarly sends a branch test in Step S2615 in accordance 
with the test result. Of course, if no further branch test exists 
to further test the peripheral communication, then PCI 300 
stops the test, and outputs an error signal. 

Assuming that NEB 2 successfully passes each SCSI 
communication test in Step S2614, then flow advances to 
Step S2616 at which point NEB 2 requests further instruc- 
tions from PCI 300. If PCI 300 returns with further 
instructions, flow returns to Step S2605, but if further testing 
is not necessary then NEB testing is ended. 

In summary, a method for testing an interactive network 
board having a LAN interface and a test interface comprises 
the steps of applying power to the board and reading a POST 
result which was executed out of board ROM via the test 
interface, and downloading a test program into the board 
RAM via the test interface. The test program is then acti- 
vated for execution out of board RAM. The board may then 
be commanded to configure a peripheral device (through 
either the LAN or the SCSI interface) to be a LAN driver or 
an SCSI peripheral. The board then interacts with the LAN 
driver or SCSI peripheral in accordance with the test pro- 
gram. Results of the test program are then output via the test 



interface to a test computer which receives these test results. 
If certain tests fail, additional test programs may be scripted 
in accordance with the type of failure. The newly scripted 
test programs will be able to perform fault detection and 

5 diagnosis, and these additionally scripted test programs may 
then be downloaded to the board RAM from the PCI. 

Once all of the tests are successfully concluded, it may be 
convenient (in the factory test environment) to flash the 
operational firmware into EPROM 222. Specifically, the last 

10 step of a testing program may be utilized to load the requisite 
firmware image into the NEB EPROM 222 prior to delivery 
(see section 4q above). The firmware flashed to EPROM 222 
may also include a unique MAC address for NEB 2. 
In the past, MAC addresses were incorporated into circuit 

15 boards using a dedicated PROM chip such as PROM 232. 
However, it has been found that if the MAC address is 
flashed into EPROM, the PROM chip is not required, while 
the MAC address can still be stored in a non-volatile way. 
(Of course, as discussed in paragraph 4q, the MAC address 

20 could also be remotely flashed into the EPROM at the same 
time the RAM firmware image is updated, after NEB 2 is 
coupled to the LAN.) In Step S2617 of FIG. 26B, NEB 
testing has been completed and each board may be desig- 
nated with its own individual identifier number, commonly 

25 referred to as a MAC address. Thus, in Step S2617 it is 
determined whether a ROM firmware image is to be stored 
in EPROM 222. If no image is to be stored, testing ends. 
However, if an image is to be stored, flow advances to Step 
S2618 where the ROM image (with MAC address) is flashed 

30 to EPROM 222. At Step S2618 it may also be desirable to 
download other data normally stored in PROM 232, such as 
board revision number, data of manufacture, tester name, 
etc., together with the MAC address. 
Two possible scenarios have been considered for flashing 

35 the ROM firmware and MAC address to EPROM 222. In the 
first case the NEB 2 has been pre-loaded with a sophisticated 
set of diagnostics for use in manufacturing tests. This 
approach limits the amount of time needed to download the 
specific tests since they will be already present in the 

40 firmware. In this case, after the tests are successful the final 
production version of the firmware is loaded into the board 
and flashed along with the MAC address and other hardware 
related information such as board revision, manufacturing 
data, and tester (Step S2618). In the second case the board 

45 will be built with the final production version of the firm- 
ware. In this case the board specific information area will be 
left blank and only this area loaded and flashed after a 
successful test execution in Step S2618. 

In summary, a method for post-test loading of program- 

50 mable firmware into an interactive network board having a 
LAN interface comprises the step of downloading a ROM 
firmware image (including the MAC address) to DRAM 220 
via the LAN interface. The integrity of the ROM image is 
then confirmed, and the board is commanded to electroni- 

55 cally erase the EPROM. The EPROM is then flashed with 
the ROM image which includes the MAC address, and the 
board is then re-booted from EPROM. 

Thus, what has been described in detail above is an 
interactive network circuit board including structure and 

60 function for coupling a peripheral to a LAN so that the 
peripheral is a responsive interactive member of the LAN. 

While the present invention has been described with 
respect to what is considered to be the preferred 
embodiments, it is to be understood that the present inven- 

65 tion is not limited to the disclosed embodiments. To the 
contrary, the present invention is intended to cover various 
modifications and equivalent arrangements included within 
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the spirit and scope of the appended claims. The scope of the 
following claims is to be accorded the broadest interpreta- 
tion so as to encompass all such modifications and equiva- 
lent structures and functions. 

What is claimed is: 5 

1. A method, for use in a local area network system 
comprising one or more network nodes and one or more 
interactive network boards each interfaced to the local area 
network by a local area network interface, for downloading 

an executable file from a remote network node to a desig- JQ 
nated interactive network board, the method comprising the 
steps of: 

activating a LAN communication program at the remote 
network node, said LAN communication program 
operating to broadcast an inquiry from the remote 
network node through the local area network for the 35 
designated interactive network board, to receive loca- 
tion information of the designated interactive network 
board in response to the broadcast inquiry, and to 
establish communication with the designated interac- 
tive network board; 20 

downloading the executable file, from the remote network 
node, over the LAN, into a RAM on the designated 
interactive network board, said executable file includ- 
ing a checksum packet; ^ 

verifying a checksum value of the executable file against 
a checksum value in the checksum packet using a 
processor on the interactive network board; 

loading the executable file from the RAM into an EPROM 
on the interactive network board in a case that the 30 
processor has verified the checksum value successfully; 
and 

receiving, in the interactive network board, at least one 
command from the LAN without putting the processor 
in an idle state; 35 

wherein in a case that the at least one command is a 
remote execute command, the processor reboots the 
interactive network board from the executable file in 
the EPROM. 

2. A method according to claim 1, wherein the step of 40 
downloading includes the step of downloading a MAC 
address into the RAM. 

3. A method according to claim 1, wherein the step of 
downloading includes the step of downloading a checksum 
value into the RAM. 45 

4. A method according to claim 1, wherein the step of 
downloading is performed immediately after an interactive 
network board test. 

5. A method according to claim 1, wherein the step of 
downloading includes the step of downloading a ROM 50 
firmware image into the RAM. 

6. A method according to claim 1, wherein the verifying 
step includes the steps of determining a checksum value of 
the executable file and comparing the determined checksum 
value with a checksum value in the checksum packet 55 
attached to the executable file, and wherein, in the case the 
determined checksum value does not equal the checksum 
value in the checksum packet, outputting an error signal. 

7. A method according to claim 1 further comprising the 
step of sending a "flash complete" signal to the LAN after 60 
the executable file has been loaded. 

8. An apparatus for downloading an executable file to an 
interactive network board, comprising: 

a LAN interface connected to said interactive network 
board, over which an executable file and at least one 65 
command is received from a LAN, said executable file 
including a checksum value; 
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a RAM, disposed on said interactive network board, for 
storing the received executable file therein; 

an EPROM, disposed on the interactive network board, 
for storing a ROM firmware image which includes 
executable files; and 

a processor, disposed on said board, for verifying the 
integrity of the executable file by performing a check- 
sum operation and comparing a checksum result to the 
checksum value in the executable file, and for receiving 
the at least one command from the LAN interface; 

wherein in the case that the processor verifies the check- 
sum value, the processor loads the executable file from 
the RAM into the EPROM; and 

wherein, in a case that the at least one command received 
from the LAN is a remote execute command, the 
processor reboots the interactive network board using 
the received executable file. 

9. An apparatus according to claim 8, further comprising 
a remote LAN device for remotely downloading through the 
LAN interface the executable file to be stored in said RAM. 

10. An apparatus according to claim 9, wherein the remote 
LAN device sends the execute command to the processor to 
execute the executable file in RAM. 

11. An apparatus according to claim 9, wherein the remote 
LAN device downloads the executable file through a test 
interface disposed on said board, 

12. An apparatus according lo claim 8, wherein the RAM 
comprises a dynamic RAM. 

13. An apparatus according to claim 8, wherein the 
interactive network board is coupled to a printer. 

14. An apparatus according to claim 8, wherein the 
EPROM comprises a flash EPROM. 

15. Apparatus according lo claim 8, wherein said proces- 
sor is for sending a "flash complete" signal to the LAN after 
loading the executable file into the EPROM. 

16. Computer-executable process steps stored on a 
computer-readable medium, the computer executable pro- 
cess steps for use in a local area network system comprising 
one or more network nodes and one or more interactive 
network boards each interfaced to the local area network by 
a local area network interface, to download an executable 
file from a remote network node to a designated interactive 
network board, the computer-executable process steps com- 
prising: 

code to activate a LAN communication program at the 
remote network node, the LAN communication pro- 
gram operating to broadcast an inquiry from the remote 
network node through the local area network for the 
designated interactive network board, to receive loca- 
tion information of the designated interactive network 
board in response to the broadcast inquiry, and to 
establish communication with the designated interac- 
tive network board; 

code to download the executable file, from the remote 
network node, over the LAN, into a RAM on the 
designated interactive network board, the executable 
file including a checksum packet; 

code to verify a checksum value of the executable file 
against a checksum value in the checksum packet using 
a processor on the interactive network board; 

code to load the executable file from the RAM into an 
EPROM on the interactive network board in a case that 
the processor has verified the checksum value success- 
fully; and 

code to receive, in the interactive network board, at least 
one command from the LAN without putting the pro- 
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cessor in an idle state, wherein in a case that the at least 
one command is a remote execute command, the pro- 
cessor reboots the interactive network board from the 
executable file in the EPROM. 

17. Computer-executable process steps according to claim 
16, wherein the code to download includes code to down- 
load a MAC address into the RAM. 

18. Computer-executable process steps according to claim 
16, wherein the code to download includes code to down- 
load a checksum value into the RAM. 

19. Computer-executable process steps according to claim 
16, wherein the code to download is performed immediately 
after an interactive network board test. 

20. Computer-executable process steps according to claim 
16, wherein the code to download includes code to down- 
load a ROM firmware image into the RAM. 

21. Computer-executable process steps according to claim 
16, wherein the code to verify includes code to determine a 
checksum value of the executable file and to compare the 
determined checksum value with a checksum value in the 
checksum packet attached to the executable file, and 
wherein, in the case that the determined checksum value 
does not equal the checksum value in the checksum packet, 
an error signal is output. 

22. Computer-executable process steps according to claim 
16, further comprising code to send a "flash complete" 
signal to the LAN after the executable file has been loaded. 

23. A computer-readable medium which stores computer- 
executable process steps, the computer-executable process 
steps for use in a local area network system comprising one 
or more network nodes and one or more interactive network 
boards each interfaced to the local area network by a local 
area network interface, to download an executable file from 
a remote network node to a designated interactive network 
board, the computer-executable process steps comprising: 

an activating step to activate a LAN communication 
program at the remote network node, the LAN com- 
munication program operating to broadcast an inquiry 
from the remote network node through the local area 
network for the designated interactive network board, 
to receive location information of the designated inter- 
active network board in response to the broadcast 
inquiry, and to establish communication with the des- 
ignated interactive network board; 



a downloading step to download the executable file, from 
the remote network node, over the LAN, into a RAM 
on the designated interactive network board, the 
executable file including a checksum packet; 
a verifying step to verify a checksum value of the execut- 
able file against a checksum value in the checksum 
packet using a processor on the interactive network 
board; 

a loading step to load the executable file from the RAM 
into an EPROM on the interactive network board in a 
case that the processor has verified the checksum value 
successfully; and 
a receiving step to receive, in the interactive network 
board, at least one command from the LAN without 
putting the processor in an idle state, wherein in a case 
that the at least one command is a remote execute 
command, the processor reboots the interactive net- 
work board from the executable file in the EPROM. 

24. A computer- readable medium according to claim 23, 
wherein the downloading step includes a step to download 
a MAC address into the RAM. 

25. A computer-readable medium according to claim 23, 
wherein the downloading step includes a step to download 
a checksum value into the RAM. 

26. A computer-readable medium according to claim 23, 
wherein the downloading step is performed immediately 
after an interactive network board test. 

27. A computer-readable medium according to claim 23, 
30 wherein the downloading step includes a step to download 

a ROM firmware image into the RAM. 

28. A computer-readable medium according to claim 23, 
wherein the verifying step includes a step to determine a 
checksum value of the executable file and to compare the 
determined checksum value with a checksum value in the 
checksum packet attached to the executable file, and 
wherein, in the case that the determined checksum value 
does not equal the checksum value in the checksum packet, 
an error signal is output. 

29. A computer-readable medium according to claim 23, 
further comprising a sending step to send a "flash complete" 
signal to the LAN after the executable file has been loaded. 
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[57] ABSTRACT 

A method and system for imaging data between two or more 
digital computers across a computer network is described, 
where the digital computers transfer data in a peer-to-peer 
mode and/or a client/server mode upon command of the 
operator. This invention address the problem of managing, 
updating and installing executable software, such as oper- 
ating systems, utilities and application software packages on 
a large number of networked computer systems. By using 
this invention properly, a system operator can transfer data 
stored on a single computer system to all or some of the 
computer system connected to the first system over a com- 
puter network and can do so without expensive electronic 
server equipment. Moreover, this invention provides the 
capability of transferring data as files, sectors or cylinders of 
disk media, thereby permitting a single operator to, through 
a generally automated procedure, simultaneously install new 
system software, configuration files and executive files on 
many computers. This invention provides an important 
improvement in the operation, maintenance and control of 
large computer networks, although it applies and works 
equally well in small network applications. In its best mode 
of operation this invention is performed on standard digital 
computer systems through the use of special purpose com- 
puter software. 

12 Claims, 15 Drawing Sheets 

Microfiche Appendix Included 
(2 Microfiche, 108 Pages) 
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METHOD AND SYSTEM FOR CLIENT/ the system bus along with the address of the receiving 

SERVER AND PEER-TO-PEER DISK processor and a data field representative of the control signal 

IMAGING to be transmitted. 

„ A ~ V ™~ TT ™ _ _ imn3xmnKf U.S. Pat. No. 4,872,006 discloses a data transmission 

BACKGROUND OF THE INVENTION 5 system in which data are transmiUed am0Dg plural stations. 

1. Field of the Invention U.S. Pat. No. 5,249,290 discloses a method of and appa- 
This invention relates to the systems and methods for ratus for operating a client/server computer network to 

copying or mirroring the binary data on one computer hard access shared server resources in response to service 

disk drive over a computer network to one or many other requests from client computers connected to the network, 

computer hard disk drives. More specifically, this invention 30 U.S. Pat. No. 5,32^522 discloses a client/server commu- 

provides a process or method for installing and/or distrib- nication system utilizing a self-generating nodal network 

uting software from one computer system to one or more wherein the method includes the steps of creating a server 

other computer systems over a computer network. nodal network tree which includes the steps of generating a 

Furthermore, this invention provides a system for solving server root node which includes both process steps for 

the often tedious problems of installing computer software 15 communicating to an operating system and service nodes, 

and distributing computer system files to a number of and process steps for building service nodes which corre- 

computer systems, providing a mechanism for fast software spond to servers within the client/server system, each ser- 

distribution on networked computers by eliminating the vice node include both process steps for advertising a 

need to use the installation utilities of each application service to the server root node and process steps for building 

program to install the software package individually on each 20 a topic node which includes both process steps for accessing 

computer. a server and process steps for building a job node for storing 

2. Description of Related Art a job request. 

It is commonly known in the related art to transfer U.S. Pat. No. 5,396,613 discloses a method for error 

computer files from one computer hard disk to another 25 recovery in client/server distributed processing systems 

computer hard disk. Similarly, it is well known to transfer using cascaded servers. 

files from computer to computer over a computer network. U.S. Pat. No. 5,421,009 discloses a method for remote 

Likewise, computer network vendors have created tool sets, installation of software over a computer network, allowing 

for use in their own labs, to transfer data from a master the user to interactively select each remote computer system 

computer disk drive to an image file on a file server and then 30 for software installation, or to provide a file containing a list 

to download the data to the target or slave computers. Other of all remote computer systems. 

existing tools will use the file server to broadcast data from u.S. Pat. No. 5,438,671 discloses a two-computer system 

an image file to the target or slave computers simultaneously and me thod where data is transferred between the computers 

(in parallel). Examples of these tools have been disclosed at as complete disk images rather than as files, 

conferences and with customers by Novell, Inc. 35 v s Pat No 5,452,459 discloses a method and apparatus 

This invention has substantial and important advantages f or allocating server access in a distributed computing 

over prior known approaches. This invention not only can environment using a scheduling process, 

use a client/server model, it can also use a peer-to-peer v s Pat No 5,459,337 disc i 0S es a method and system 

model not available with computer network vendor tool sets for monitorin the perform ance 0 f servers across a network 

or prior used disk-to-disk copying. Unlike, pnor approaches 40 and for suggesting an appropriate server to a client request- 

this invention can be used without a network file server and m a wherein a lmm of ^ afe laced {n 

still can copy computer data from one computer hard diskto yarious dien(s in me oetwork b a Broker .p er f orm ance 

many computer hard disks over a computer network, by Mechanism 

using the peer-to-peer mode of operation. Moreover, the / for 

peer-to-peer mode of operation provides important advan- 45 . . . . . ■ . / . . j • j 

tages in terms of transfer speed and lower cost. The speed rm S ^ a be,ween «»P«A>utput ^ces and mam or 

f .... j, . 4 t . expanded storage under dynamic control of independent 

advantage is realized by using a one step process rather than . ■T. 4 . , , 

,u . ■ J* *u i- .# j 1 r indirect address words, 
the two step process required for the client/server model of 

operation. In the invention's peer-to-peer mode, the data is u s - Pat - No - 5,465,351 discloses a method and system 
distributed from the master computer to the slave computers 50 for memorv management of a client/server computing net- 
in a single step. The cost advantage is achieved by not work. 

requiring a network file server to accomplish the one to U.S. Pat. No. 5,491,694 discloses an apparatus and 

many data imaging. Network file servers are costly to method for establishing "virtual connections" through a 

purchase, install and maintain. packet switched data communications network, the network 

For general background art the reader is directed to U.S. 55 including a plurality of end systems and switches connected 

Pat. Nos. 4,866,664, 4,872,006, 5,249,290, 5,325,527, by links, to allocate a shared resource among competing 

5,396,613, 5,421,009, 5,438,671, 5,452,459, 5,459,837, devices. 

5,461,721, 5,465,351, 5,491,694, 5,495,611, 5,506,902, U.S. Pat. No. 5,495,611 discloses a method and apparatus 

5,513,126, 5,513,314, 5,515,508, 5,515,510, 5,517,645, for dynamically loading an ABI OS device support layer in 

5,517,668, 5,522,041, 5,526,490, 5,528,757, 5,537,533, 60 a computer system. 

5,537,585, 5,542,046 each of which is hereby incorporated U.S. Pat. No. 5,506,902 discloses a data broadcasting 

by reference in its entirety for the material disclosed therein. system for the low-cost delivery of character-heavy data 

U.S. Pat. No. 4,866,664 discloses an interprocessor mes- such as newspapers and magazines, 

sage communication synchronization apparatus and method U.S. Pat. No. 5,513,126 discloses a method for a sender 

for a plurality of processors connected to a system bus where 65 to automatically distribute information to a receiver on a 

one processor desiring to send a control signal to another network using devices and communication channels defined 

processor, broadcasts an input/output write instruction on in the receiver profiles. 
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U.S. Pat. No. 5,513,314 discloses a fault tolerant NFS one computer simultaneously, over a network, where the 

server system and mirroring protocol for the retrieval of data method can function upon user command either under a 

files including a client system connected to a data commu- client/server model or a peer-to-peer model of operation, 

nication network. Accordingly, it is the primary object of this invention to 

U.S. Pat. No. 5,515,508 discloses a object-oriented client/ 5 provide a process for installing computer application pro- 
server facility (CSF) and networking service facility (NSF) grams on multiple computer systems simultaneously over a 
interfacing between application programs residing in client computer network. 

and server nodes of a distributed services network. i t is a further object of this invention to provide a process 

U.S. Pat. No. 5,515,510 discloses a communications for mirroring data files on multiple computer systems simul- 

internetwork system connecting a client node array to a 10 taneously over a computer network. 

resource array. It j s further object of this invention to provide a method 

U.S. Pat. No. 5,517,645 discloses a method and system for copying binary computer data from one computer hard 

for managing the connection of client components to an disk drive to one or more other computer hard disk drives, 

interface implemented by a sever component. J5 which does not require the use of a computer file server. 

U.S. Pat. No. 5,517,668 discloses a distributed computing It is a further object of this invention to provide a system 

system having a distributed protocol stack. for mirroring computer data from one computer disk drive to 

} U.S. Pat. No. 5,522,041 discloses a data processor and a another computer disk drive in a peer-to-peer computer 

/ data transfer method for efficiently transferring data between communications model. 

I a plurality of information processing devices as in a client 20 It is a further object of this invention to provide a system 

I server system. for mirroring computer data from one computer disk drive to 

U.S. Pat. No. 5,526,490 discloses a data transfer control another computer disk drive in a client/server computer 

unit using a control circuit to achieve high speed data communications model. 

transfer. It is a further object of this invention to provide a method 

U.S. Pat. No. 5,528,757 discloses a communication net- 25 for mirroring computer data between one computer disk 

work system in which a plurality of information processing drive to another computer disk drive that permits the user to 

equipments are connected with a communication line for select between a client/server and peer-to-peer computer 

communication of a message. communications. 

U.S. Pat. No. 5,537,533 discloses a system for remote It is a further object of this invention to provide a method 

mirroring of digital data from a primary network server to a and system for mirroring computer data from disk drive to 

remote network server, which includes a primary data trans- disk drf ve that improves the cost performance of client/ 

fer unit and a remote data transfer unit which are connected server systems available in the art. 

one with another by a conventional communication link. It is a further object of this invention to provide a 

/ U.S. Pat. No. 5,537,585 discloses a data storage manage- 35 computer data mirroring system that incorporates data com- 

/ ment system for networked interconnected processors, pression. 

| including a local area network and a storage server. It is a further object of this invention to provide a 

U.S. Pat. No. 5,542,046 discloses a peer to peer connec- computer data imaging system that has the capability of 

tion authori/xr which includes a system authorizer imaging a single disk partition, multiple disk partitions, or 

mechanism, a client connection manager, and a server 40 the entire hard disk, from one computer hard disk to one or 

connection manager. mor e other computer hard disks simultaneously. 

None of these prior related art references discloses a Additional objects, features and advantages of this inven- 

system for imaging (or mirroring) binary data from one tion will become apparent to persons of ordinary skill in the 

computer hard disk drive over a computer network to one or art upon reading the remainder of the specification and upon 

many other computer hard disk drives either through a 45 referring to the attached figures. 

client/server mode or a peer-to-peer mode, to provide a These objects are achieved by a set of two computer 
mechanism or process for rapid software distribution on programs, referred to by the inventor as IMGBLSTR and 
networked computers which eliminates the necessity of IMGSLAVE. The IMGBLSTR program is the primary con- 
using each application's install utility individually on each trol program while the IMGSLAVE program is used for 
computer, 50 listening for data from the IMGBLSTR program across the 

network and writing such data to the local disk drive. 

MICROFICHE APPENDIX qiie IMGBLSTR program operates in five modes of 

This specification includes a Microfiche Appendix which operation. These are: 

includes 2 pages with a total of 108 frames. The microfiche 55 1. IMGBLSTR reads the data from the disk drive of the 

appendix includes computer source code of one preferred master computer, compresses the data, and writes it 

embodiment of the invention. In other embodiments of the (uploads it) to an "image file" resident on a network file 

invention the inventive concept may be implemented in server. This is the client/server model or mode of 

other computer code, in computer hardware, in other operation. 

circuitry, in a combination of these or otherwise. The Micro- 60 2. In connection with performing mode 1 above, IMG- 

fiche Appendix is hereby incorporated by reference in its BLSTR broadcasts (simultaneously sends in parallel) 

entirety and is considered to be a part of the disclosure of this the data that is being uploaded to the image file on the 

specification. network to all computers running the IMGSLAVE 

program. This mode of operation is a combination of 

SUMMARY OF THE INVENTION 6J client/server and peer-to-peer. 

It is desirable to provide a method and system for install- 3. IMGBLSTR reads the data from the local computer 

ing computer software and computer data files on more than disk drive and broadcasts it on the wire (network) to 
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computers running the IMGSLAVE program. The 
IMGBLSTR program does not upload the data to an 
image file on a network file server, rather the data goes 
directly to the slave computers running the 
IMGSLAVE program. This is the peer-to-peer mode of 
operation. 

4. IMGBLSTR reads the data from an image file located 
on a network file server, decompresses it, and writes it 
to its own local computer hard disk drive. This the 
download process for the client/server model. 

5. While performing operation mode 4 above, IMGBL- 
STR broadcasts the data that is being downloaded from 
the image file on the network to all computers running 
the IMGSLAVE program. This is a combination client/ 
server and peer-to-peer mode. 

The IMGBLSTR program determines which mode to use 
through either a series of menu options presented to the 
operator, or through commands from the operator entered on 
the command line when the program is launched. 

The IMGSLAVE program operates in only one mode of 
operation. Specifically, it opens a communication socket on 
the network, listens for data received on that socket, and then 
processes the data received on the socket. Each packet of 
data received on the socket contains a command field which 
tells IMGSLAVE what the data contained in the packet is 
used for and how the data is to be processed. The commands 
in the command field are: 



Command 


Performed by 


Function 


Drive Geometry 


Master 


Compare geometry of master image 
with slave 


RSVP 


Slave 


Response to master to indicate 
participation in download 


Conform 


Master 


Acknowledgment that slave has 


Download 




joined the process and that master 
knows slave is ready 


Sector Data 


Master 


Write data to receive buffer 


Sector Data & 


Master 


Write data to receive buffer and flush 


Flush 




data to disk 


Skip TYack 


Master 


No data in current track - Skip this 




track 


Resend Request 


Slave 


Slave missed data - Please resend 


End of Data 


Master 


Master is finished sending data - 
Ready for a slave request 


Done 


Master 


Image complete - Exit program 


Disconnect 


Slave 


Slave response to master "done" 
command - Slave disconnecting 


Disconnect 


Master 


Master acknowledges slave 


Acknowledge 




disconnect 



Current source code for both the IMGBLSTR and the 
IMGSLAVE programs are included and listed in the Micro- 
fiche Appendix included with this patent application. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 depicts a system diagram of a computer network 
having a source (master) computer and a number of desti- 
nation (slave) computers connected to each other electroni- 
cally. 

FIG. 2 depicts a system diagram of a computer network 
using the prior approaches utilizing client/server modes of 
operation for transferring data from one computer to other 
computers across a network. 

FIG. 3 depicts the top level state diagram of the master 
computer ("IMGBLSTR") program/process component of 
the invention. 

FIG. 4 depicts the top level state diagram of the slave 
computer ("IMGSLAVE") program/process component of 
the invention. 
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FIG. 5 depicts the top level process flow chart of the 
master computer component of the invention. 

FIG. 6 depicts the detailed flow diagram of the process 
menus steps of the master computer component of the 
5 invention. 

FIG. 7 depicts the detailed flow diagram of the upload 
image step of the master computer component of the inven- 
tion. 

30 FIG. 8 depicts further detail of the read head step of the 
upload image section of the master computer component of 
the invention. 

FIG. 9 depicts further detail of the broadcast head step of 
the upload image section of the master computer component 
15 of the invention. 

FIG. 10 depicts further detail of the download image step 
of the master computer component of the invention. 

FIG. 11 depicts further detail of the fill compress buffer 
from file step of the down load image step of the master 
20 computer component of the invention. 

FIG. 12 depicts further detail of the get byte from com- 
press buffer step of the down load image step of the master 
computer component of the invention. 
25 FIG. 13 depicts further detail of the write data to head 
buffer step of the down load image step of the master 
computer component of the invention. 

FIG. 14 depicts further detail of the flush head buffer step 
of the write data to head buffer step of the master computer 
30 component of the invention. 

FIG. 15 depicts a flow chart diagram of the slave com- 
ponent of the invention, which is a detailed flow diagram of 
the current preferred embodiment of the Slave computer 
process of the invention. 

35 DETAILED DESCRIPTION OF THE 

INVENTION 

FIG. 1 shows a computer network having a source 
(master) computer 101 and a number of destination (slave) 

40 computers 102fl, 102/?, 102c, 102J, 102^, 102/7 connected to 
each other electronically as may be used in the peer-to-peer 
mode of operation of the invention. A typical stand-alone 
computer may include the following components: a proces- 
sor; internal memory; a disk storage device; a display 

45 device; and an input device. The electrical connection 103 
provides a communication channel between the computer 
systems. The use of this invention does not require that the 
connection between the computer systems, as designated 
103, necessarily be electrical. Other alternative methods of 

50 conductivity include, fiber optical, RF, and/or light wave 
transmission and detection. Often these types of communi- 
cations channels are referred to as "networks," "local-area- 
networks" (LANs), and "wide-area-networks" (WANs). 
Typically, each computer is capable of operating as a stand- 

55 alone system. With the addition of the electrical connection 
103 the computers are also capable of sharing information 
(for example data files and e-mail). The applicants' present 
invention extends the capabilities of individual computer 
systems connected over a computer network by providing 

60 disk imaging from one computer to another computer over 
a network. Such disk imaging provides a solution to the 
problem of installing, backing up, maintaining, and upgrad- 
ing of computer operating system software, computer sys- 
tem utility software, and application programs. This 

65 invention, which operates either with or without a computer 
network server, permits a single computer system to be 
designated as a "master" and to transfer data from its disk 
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drive or drives to one, some or all of the other computers on state 301 the master computer is initialized for communi- 

the network, designated as "slaves." cation with slave computers. The process goes from state 

FIG. 2 depicts a system diagram of a computer network 301 to state 302 when the master computer broadcasts its 

employing the traditional network server hard ware 201 .This disk drive geometry to the slave computers. In this Send 

system is well known for providing a method of transferring 5 Geometry Packet state 302 the master computer sends the 

data to and from the network server and from and to the master computer drive geometry to slave computers on the 

individual computers on the network. These prior send IPX socket. The "currently connected clients" display 

approaches, typically are referred to as "client-server" sys- is initialized. Geometry packets are sent periodically to the 

terns. In a traditional client-server system, data is transferred s i aV e computers. Geometry packets, in the preferred 

from a client computer 202 to the network server 201, or is 10 embodiment of the invention, include the following disk 

transferred from the server 201 to one or more of the client drive information for the master local disk drive: maximum 

computers. While applicants' invention supports client- cylinders; maximum heads; maximum sectors, image file 

server network systems, the most important achievement of partition start cylinder; and image file partition end cylinder, 

this invention is that it provides the capability of transferring Geometry packets also include information on the IPX 

data, files, and disk sectors from any computer on the 35 network sockets, including: the network address; the node 

network to any other computer on the network with or address; and the socket number. Error conditions are moni- 

without a network server, thereby dramatically decreasing tored and the master computer waits for RSVP packets from 

the difficulty and complexity of computer network manage- the slaves. When the master computer receives an RSVP 

ment. Where a network server 201 is employed in the f rom the slave the master adds the slave (or client) to its list 

network the "master 1 ' computer 202a is provided with the 20 an d sen d an ACK packet to the slave 303. When the 

capability of transferring data either to the network server connection between the master and one or more slaves is 

201 and/or to one or all of the "slave" computers 202b, 202c, either completed, terminated by an operator command, or 

202rf, 202e, . . . , 202/1. This inventions supports networks terminated by a timeout, the master process goes to the Send 

utilizing client/server modes of operation for compatibility Data Mode state 304. The Send Data Mode state 304, in 

with existing networks. It also supports and provides peer- 25 combination with the Send Head Broadcast state 306 and the 

to-peer operation to permit network management without Lo op t0 Send All Tracks state 305, performs the upload 

the considerable expense of network server hardware and image, broadcast head, broadcast skip head, broadcast given 

simultaneously providing a significant improvement in data head, and the send IPX packet tasks. In the event that a 

transfer efficiency across a computer network. Resend Request is received the process goes from the Send 

In its best mode of operation, the present invention 30 Data Mode state 304 to the Queue Req. On Resend List — 
operates through coordinated use of two computer system Perform Throttle Processing 307. During this state, incom- 
communications programs: IMGBLSTR and IMGSLAVE. ing packets are processed, resend requests are processed by 
IMGBLSTR is designed to operate on the "master" servicing the resend queue by sending data packets to slaves, 
computer, while IMGSLAVE is designed to operate on the resend requests are recorded, the resend list is processed and 
"slave" computer. In the current preferred embodiment of 35 tracks are re-transmitted. These tasks are processed in con- 
the invention each program is written in the C programming junction with state 306. In the event that no more data 
language and operates on a DOS operating system. remains to be sent, the process moves to the Allow Slaves to 
However, other equivalent embodiments of the invention Catch- Up state 308. This state finishes processing of broad- 
may be created in other computer languages, including but casts and handles late resend requests. The transition of the 
not limited to C++, Pascal, and assembly code, and may be 40 process from state 308 to state 309 is accomplished as 
designed to operate on other computer operating systems, follows: (1) a timer indicates it is time to send a packet; (2) 
including but not limited to UNIX, Windows and Macln- a packet of data is sent 309; and (3) the process returns 
tosh. The following discussion of the steps of the process of automatically to state 308 to wait for the next timer indica- 
tes invention correspond to programs, sub-programs, and tion. Thus, when the timer has run, the process moves from 
routines in IMGBLSTR and IMGSLAVE best mode of the 45 the Allow Slaves to Catch-Up state 308 to Send "End of 
invention. Following this discussion of the essential steps of Data" Packet state 309, which sends farewell broadcast 
this process is a complete list of the source code for each packets, and back to state 308. When the transfer is complete 
program. This source code is provided as part of this (when a timeout occurs), the process moves to the Farewell 
disclosure, to provide a fully enabling description of the to Slaves state 310, which in combination with the Send 
invention. It is suggested that the reader refer to this source 50 "Goodbye" Broadcast state 312 and the Remove Slave From 
code for additional detailed description as the reader reviews List Send "Goodbye" to Specific Slave state 311, performing 
the following figure by figure discussion of the process of the say Goodbye to Slaves and Processing Image Packets 
the invention. tasks. 

The following description of the top level state diagrams FIG. 4 depicts the top level stale diagram of the slave 

of the "master" computer and the "slave" computer is 55 computer ("IMGSLAVE") program/process component of 

provided to give the reader an overview of the handshaking the invention. Beginning with the Hook-Up with Master 

and data processing process of the invention. A detailed state 401 the slave computer attempts to form a communi- 

breakdown of each subprocess, task or program is given in cations link with the master computer. After a geometry 

the later detailed descriptions of the process flow charts and packet is received from the master, the slave process moves 

the best mode of operation of the invention is provided in the 60 to the Send RSVP state 402, where the slave checks the disk 

listing of software source code included in this description drive geometry for compatibility and acknowledges receipt 

following the description of the detailed subprocesses, tasks, of the geometry information with an RSVP. After the slave 

and/or programs. process receives a RSVP acknowledge from the master, the 

FIG. 3 depicts the top level state diagram of the master process enters the Download Data state 404. Data is received 

computer ("IMGBLSTR") program/process component of 65 via transitioning between the Download Data state 404 and 

the invention. The master computer process begins by the Process Data Packet state 407. The Process Data Packet 

entering the Wait for Slave Connection state 301. In this state 407 processes the received data by checking to see if 
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the head is at a valid position, and storing the received data computer to a network server computer and/or, if the broad- 
in a buffer. A test is performed to determine if the designated cast feature is enabled, broadcasting the data to the image 
slot is not empty, wherein a "lost data" resend request is sent. slave computers on the network. Initially, upload image 
The process of the invention provides the capability of program is initialized 701. This initialization step is neces- 
sending resend requests through the Send Resend Request 5 sary to provide needed data. A test 712 is made to determine 
state 408. If a "flush" packet is received (a "flush" packet is whether the invention is operating in the client/server mode, 
a special type of data packet, containing an attribute to If it is, an image file is opened 702 and an image header is 
indicate that when the data is copied to the image file, that written 703. The drive head buffer is read 704. A test is 
the image file should then be flushed to disk), the Flush performed to determine whether the data is to be broadcast 
Complete Track state 405 is entered, where if the buffer is 10 705 to multiple slave computers. If the data is to be 
complete, it is written to disk and the "good upto" track is broadcast the broadcast is performed 707, if not the process 
updated, removing the track from the "missing list." If the passes through the null state 706 before once again testing 
buffer is incomplete, this state 405 sends a "lost data" resend to determine if the process is in the client/server mode 713. 
request and adds the track to the "missing list." When the If it is, the data is compressed and written to a file 708. Data 
transfer of data is complete, a "End of Data" packet is J5 compression is accomplished, currently by a "Run-Length 
received from the master, leading the slave process to the Encoding 1 ' scheme well known in the art. Next, System 
Farewell to Master state 409, where once a "goodbye" is pointers are incremented 709 and if the system has not 
received from the master, the Random Delay — Send "Good- reached the stop cylinder 710 the process continues to read 
bye" to Master state 410 is entered to send a "goodbye" is the head buffer 704, broadcasts the data 707, compresses the 
send to the master. Thereby, finishing the slave process. 2 o ^ ata » anc * adjusts trie system pointers. After the stop cy Under 
FIG. 5 depicts the top level process flow chart of the is reached 710, the process performs the clean-up step 711 
master computer component of the invention. In its current by closing files, resending missed tracks and saying "good- 
best mode of operation, the process of this invention begins bye" to slave (client) computers. 

with the initialization 501 of the master. During this initial- FIG. 8 depicts further detail of the read head step of the 

ization step 501 the user license is verified, usage parameters 2 5 upload image section of the master computer component of 

are checked the MAC address of the computer is acquired the invention. This program step reads a head worth of data 

and displayed, the local drive geometry is retrieved, all from a selected local hard disk drive at the current cylinder 

needed buffers are allocated, and the number of hard disk and current head location. Errors that are encountered, are 

drives installed in the computer is determined. Next, the reported. The process of the invention is aborted after five 

command line process step is performed 502, where the 30 retries on errors. However, because CRC type errors are 

command line is parsed, setting flags and/or calling the recoverable, they will not count towards aborting the pro- 

functions to process each command. Next, menus are pro- cess. First, this sub-process is initialized 801, providing 

cessed 503. The process menu step calls other functions to access to the necessary variables. Next, the data in the 

get needed information for the execution of the program. A designated current head is read 802. If a read error occurs 

test is made as to whether the process is required to upload 35 803 the read of head data is attempted again, up to five times 

data ("image") to a slave or download data ("image") 504. 805. If errors continue beyond five tries 805 an error 

If the process is required to upload data then the upload message is displayed 806 and the program is exited 807. 

image step 505 is performed to upload the image, drive data, Otherwise, if the data is read without error then the process 

to the image file. If the process is not required to upload data passes through the null state 804 and the program returns to 

then the download image step 506 is performed, which 40 the upload image process step 505 as shown in figure seven, 

accomplishes the downloading of the image (drive data). If FIG. 9 depicts further detail of the broadcast head step of 

a file name was specified by the operator, it is opened and the the upload image section of the master computer component 

drive data is read from the file. Lastly, the clean-up step 507 of the invention. The function of the broadcast head 

is performed to reset all affected computer systems on the program — subprocess is to broadcast the drive head data 

network. 45 (headbuffer) to the image slaves using the send IPX socket. 

FIG. 6 depicts the detailed flow diagram of the process Data is sent 512 bytes at a time, equal to a single sector of 

menus steps of the master computer component of the disk data. On the last sector sent, the command to flush the 

invention. The process menus program process calls other data, that is, to write it to the hard drive, is sent. The first step 

program and/or functions to get the needed information for in the broadcast head process is to initialize the data for 

the process of the invention. Where the requested informa- 50 broadcast 901. The process of sending packets of data 905 

tion has already been entered on the command line, the is performed one sector at a time. After it is determined that 

associated menu is not displayed. First, the program vari- an additional sector of data is in the head 902, the sector data 

ables are initialized 601. Next, the desired process function is packaged 905 or prepared for broadcast, a delay is 

is requested 601, allowing the operator to specify whether provided 903 to insure correct interpacket data broadcast, 

the operator wants to upload or download. Next, the get 55 then the packet is sent 905. The broadcast head process is 

partition 603 step is performed to display the local drive finished when no further sectors remain for transfer, 

partition table and to allow the operator to specify the FIG. 10 depicts further detail of the download image step 

partition to be imaged. The next step is to get the image file of the master computer component of the invention. This 

name 604, during which the operator is prompted to provide program sub-process of the invention performs the function 

the name of the image file, including the complete path. 60 of downloading the image (disk drive data). If a file name is 

Next, the broadcast state is requested 605, that is, whether specified by the operator, it is opened and the disk drive data 

the operator wants to send the drive data to other slave is read from the file. If the broadcast feature is enabled, the 

computers via broadcast packets. data is broadcast to the image slaves on the network. The 

FIG. 7 depicts the detailed flow diagram of the upload first step is to initialize 1001 the needed data and to set the 

image step of the master computer component of the inven- 65 head buffer pointer to 0. Next, an image file is opened 1002 

tion. The upload image program process performs the func- if needed and if the image file name is valid. The image 

tion of uploading the image (drive data) from a master header data is read 1003 and a check is made for the proper 
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drive geometry. If the image geometry is equal to the drive 1405 to disk and the current head and cylinder data is 

geometry 1004 then the data is decompressed 1006 using adjusted 1406 prior to returning to the write data to head 

well known "Run-Length" decompressions schemes. Once buffer process of FIG. 13. 

the data is decompressed it is written 1007 to the head FIG. 15 depicts a flow chart diagram of the slave corn- 
buffers. After data is written to the head buffer, this part of 5 ponent of the invention, is a detailed flow diagram of the 
the process is complete. If the image geometry does not current preferred embodiment of the Slave computer process 
match the drive geometry, of step 1004, an error message of the invention. The IMGSLAVE is the slave component or 
1005 is displayed, process of the invention that provides the parallel disk image 
FIG. 11 depicts further detail of the fill compress buffer process. The slave uses an IPX socket to listen for data from 
from file step of the down load image step of the master 10 the image master. A special header in the data from the 
computer component of the invention. This function fills the master determines the function the slave will perform. The 
compress buffer by reading a head size (maximum sectors IMGSLAVE program cannot create or restore an image 
times 512) of data from the image file. If an error occurs without the IMGBLSTR program. Its function is to listen to 
during the read, an error message is displayed. First, the data lhe network for data from the IMGBLSTR, to retrieve data 
is initialized 1101 to provide data for the process. Next, the 15 &P m ^ network ™? 10 wri * e U t0 ^ e slave /f ^ de- 
compress buffer file size is read 1102 and tested 1103 for ™ c slave P r ° cess be S ms b > ifialamg 15 °\ ^ata for 

error If an error is encountered, it is displayed 1105, P^ss^ 

... n 11A , . i « i . * the master the slave responds with an RS VP 1503. Next, the 

otherwise ^a null state 1104 is used land the process returns to ^ fof an R ' svp acknowled 1S04 from the 

the download image process of the invention of FIG. 10. master ^ ^ receipt of me Rsvp acknow i edge> a test 
FIG. 12 depicts further detail of the get byte from com- 20 1505 is made t0 determine whether the register for download 
press buffer step of the down load image step of the master ^ valid, if not, a message indicating that the transfer is 
computer component of the invention. This process subpro- unusable is sent 1506. Alternatively, if the register for 
gram functions to retrieve a byte from the compress buffer. download is valid, then the data is downloaded 1507 to the 
When the compress buffer is empty, it is refilled by reading slave. Error checking 1508 is performed and errors are 
data from the image file. First, the data is initialized 1201 for 2 s displayed 1509 if detected. If no errors are detected, a 
use in the process. Next the compress pointer is tested 1202 download complete message is displayed 1510. 
to determine if it is greater than the size of the compress The following is a listing of the computer source code 
buffer. If it is, the compress buffer is filled 1203 from the which is the current best mode preferred embodiment of the 
image file. The compress pointer is then reset 1204. The byte invention. The reader can, by consulting this source code, 
pointed to by the pointer/counter is returned 1206 and the 30 learn all that is necessary to produce and use the invention, 
process returns to the download image process of FIG. 10. The previous description, including the listed source code, 
In the event that the compress pointer does not exceed the describes the current preferred best mode embodiment of the 
size of a buffer, test step 1202, the process goes through a invention as it is performed on personal computers con- 
null state 1205 and returns 1206 the byte pointed to by the nected through a computer network with or without a 
compress pointer and returns to the download image pro- 35 computer server. The software programs which are used to 
cess practice this invention typically reside in the memory and/or 

FIG. 13 depicts further detail of the write data to had d |f stora ^ , me f ium . of **. worked computers. 

L ir c a\~ j i j • > c . While the current best mode of the invention is used on 

buffer step of the down load image step of the master ^ { {{ ^ not nece that it be limited in 

computer component of the invention This step functions to ^ M computational device which has a long term 

take the byte of data passed to it and write it to the head 40 slorage me dium, for example: a disk drive, a tape drive, a 

buffer the number of times indicated by the compress CD or optical storage medium; and can be networked to 

counter. This is part of the process of decompressing the olher computational devices. The size, configuration or 

image file. When the head buffer is full, it flushes the data purpose of the computational device does not limit the use 

to the hard disk drive. First, the data required is initialized 0 f this invention to image long term stored data from one 

1301 . Next, the data is written into the head buffer 1302. The 45 computational device to another in either a peer-to-peer 

head buffer pointer is incremented 1303. A test 1304 is made mode or a client/server mode of operation. Furthermore, 

to determine whether the head buffer is full. If it is, the head while this invention is performed, in its current best mode, 

buffer is flushed to disk 1305 and the pointers/counters are by software written in the C programming language, alter- 

adjusted 1306. A test 1308 is then made to determine native computer languages can equivalently used. The soft- 

whether the compress count is complete. If it is, the process 50 ware source code provided as part of the disclosure of this 

returns to the download image of FIG. 10. If it is not, then patent application, shows in detail how the functional steps 

the process returns to step 1302 to move a byte into the head of the invention are performed. Of course, it is contemplated 

buffer. If the head buffer, of step 1304, is not full, a null state that the inventive concept of this invention may be imple- 

1307 is passed through before the compress count test of mented through other techniques and in other embodiments 

step 1308. 55 and in other computer languages. The computer source code 

FIG. 14 depicts further detail of the flush head buffer step is provided to describe the best mode of operation of the 

of the write data to head buffer step of the master computer invention, such a best mode may evolve and change over 

component of the invention. This step functions to flush the time, after the filing of this application without altering the 

head buffer data to disk. The entire head buffer is written in fundamental inventive concept of the method, which is the 

one command. All needed pointers, counters, etc., are 60 imaging of computer data from one computer to one or more 

updated along with screen information. Also, if the broad- others over a network using a peer-to-peer method and still 

cast feature is enabled, the head data is broadcast to the remain compatible with a client/server mode of operation, 

image slaves. First the data is initialized 1401 for use in this without requiring special purpose network server hardware. 

process. Next, a test 1402 is made to determine if the process We claim: 

is in the broadcast mode. If it is, the head data is broadcast 65 1. A method for imaging data between two or more digital 

1403 to all image slave computers. If not, the process goes computer systems across a computer network the method 

through a null state 1404. The head buffer is then written steps comprising: 
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(A) networking a master computer to a first slave com- 
puter and a second slave; 

(B) initiating the imaging of data on said master com- 
puter; and 

(C) responding to the requests for data imaging from said 
master computer on said first slave computer and said 
second slave computer. 

2. A method for imaging data between two or more digital 
computer systems across a computer network, as recited in 
claim 1, where said initiating the imaging of data step further 
comprises the steps of: 

(1) determining the type of imaging which is desired 
between the computer systems; 

(2) transferring the image data between said slave com- 
puter and said master computer; and 

(3) broadcasting the transferred image data from a single 
master computer system to more than one slave com- 
puter system. 

3. A method for imaging data between two or more digital 
computer systems across a computer network, as recited in 
claim 1, wherein said initiating the imaging of data step 
further comprises the steps of: 

(1) receiving computer system information from said 
master computer; 

(2) transmitting said received computer system 
information, wherein said computer system informa- 
tion includes handshaking information, to said master 
computer; 

(3) downloading said transferred image data from said 
master computer and to said slave computer and for 
storing the image data in a digital computer system; and 

(4) handling errors incurred in the downloading of the 
image data from said master computer. 

4. A method for imaging data between two or more digital 
computer systems across a computer network, as recited in 
claim 2, wherein said determining the type of imaging step 
which is desired between the computer systems, further 
comprises the steps of: 

(a) processing command line information from the system 
operator; and 

(b) processing menu information for gathering necessary 
information from the system operator and the digital 
computer systems. 

5. A method for imaging data between two or more digital 
computer systems across a computer network, as recited in 
claim 2, wherein said transferring image data between said 
slave computer and said master computer step, further 
comprises the steps of: 

(a) opening a file containing the data to be imaged; 

(b) writing an image header for recording the image 
header data; 

(c) retrieving image data into a computer system; and 

(d) minimizing the data storage requirements of the 
retrieved image data. 

6. A method for imaging data between two or more digital 
computer systems across a computer network, as recited in 
claim 2, wherein said broadcasting the transferred image 
data step, further comprises the steps of: 

(a) packaging digital computer system sector data; and 

(b) sending said packaged digital computer system sector 
data across a network to one or more digital computer 
systems. 
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7. A system for performing peer-to-peer imaging of infor- 
mation stored in a digital computer storage media across a 
digital computer network comprising: 

(A) a first digital computer system having a first disk 
drive; 

(B) a second digital computer system having a second 
disk drive and a third digital computer system having a 
third disk drive; 

30 (C) a network communication device electrically connect- 
ing said first digital computer system to said second 
digital computer system; and 
(D) a means for simultaneously imaging data stored on 
said first digital computer system to said second digital 
computer system and said third digital computer system 
thereby duplicating all data stored on said first disk 
drive of said first digital computer system to said 
second disk drive on said second digital computer 
20 system and to said third disk drive on said third digital 
computer system. 

8. A system for performing peer-to-peer imaging of infor- 
mation stored in a digital computer storage media across a 
digital computer network, as recited in claim 7, further 

25 comprising: 

(F) a third digital computer system; and 

(G) a means for broadcasting image data stored on said 
first computer system to said second digital computer 

30 system and said third digital computer system. 

9. A system for performing peer-to-peer imaging of infor- 
mation stored in a digital computer storage media across a 
digital computer network, as recited in claim 7, further 
comprising: 

35 (H) a means for compressing the volume of information 
to be imaged. 

10. A system for performing peer-to-peer imaging of 
information stored in a digital computer storage media 
across a digital computer network, as recited in claim 7, 

40 wherein said system is operable in a client/server network 
environment. 

11. A system for performing peer-to-peer imaging of 
information stored in a digital computer storage media 

45 across a digital computer network, as recited in claim 7, 
wherein said system is operable in a network without 
electronic server hardware. 

12. A networked computer system comprising: 

(A) a means for initializing variables for use by a software 
50 program for performing data imaging on digital com- 
puters across a computer network; 

(B) a means for selecting the type of imaging of the digital 
computer data; 

(C) a means for uploading to simultaneously transfer 
digital computer data from one digital computer to two 
or more other digital computers, wherein each digital 
computer operates in a peer-to-peer mode; 

(D) a means for downloading to receive data from a 
60 digital computer to another digital computer; and 

(E) a means for error detection and reporting for identi- 
fying and reporting any errors that occur during said 
upload or said download routines. 
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